Wanted: small C program to drop all capabilities but cap_sys_ptrace
Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. On an Ubuntu system, this is very similar to what DHCP and PING do -- setuid 0, however they drop all privs except cap_net_rawio at the start. Existing code can be used: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/droppriv.dpatch http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/deroot-client.dpatch Basically, I need someone to write this shim for me. The long term solution is probably to just package Wine such that the wine binary itself has cap_sys_ptrace, however currently Ubuntu has no support for this kind of extended attribute in the packaging system so workarounds like the above for DHCP need to be done. I suspect other distros have similar issues. Thanks, Scott Ritchie
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 09/29/2010 03:14 PM, Scott Ritchie wrote: Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. Pardon my ignorance but why is Ubuntu restricting the ptrace'ing of processing belonging to the same uid? On an Ubuntu system, this is very similar to what DHCP and PING do -- setuid 0, however they drop all privs except cap_net_rawio at the start. Existing code can be used: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/droppriv.dpatch http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/deroot-client.dpatch Basically, I need someone to write this shim for me. The long term solution is probably to just package Wine such that the wine binary itself has cap_sys_ptrace, however currently Ubuntu has no support for this kind of extended attribute in the packaging system so workarounds like the above for DHCP need to be done. I suspect other distros have similar issues. Doubt that Fedora has that problem as they are using SELinux to restrict what processes can do. There is a policy for Wine and rpm supports the setting of the correct SELinux context on rpm installation/upgrade time. bye michael
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 29 September 2010 15:42, Michael Stefaniuc mstef...@redhat.com wrote: On 09/29/2010 03:14 PM, Scott Ritchie wrote: Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. Pardon my ignorance but why is Ubuntu restricting the ptrace'ing of processing belonging to the same uid? See http://lkml.org/lkml/2010/6/29/401 for some background on this. I think the conclusion from that thread was essentially that ptrace restrictions and the like should be done using something like SELinux instead.
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
Scott Ritchie sc...@open-vote.org writes: Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. I don't think that's a good idea. CAP_SYS_PTRACE allows access to any process, so it's a lot more dangerous than the standard ptrace checks that Ubuntu decided to break. Going back to the default behavior is probably safer than making Wine setuid... -- Alexandre Julliard julli...@winehq.org
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 09/29/2010 07:12 AM, Alexandre Julliard wrote: Scott Ritchie sc...@open-vote.org writes: Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. I don't think that's a good idea. CAP_SYS_PTRACE allows access to any process, so it's a lot more dangerous than the standard ptrace checks that Ubuntu decided to break. Going back to the default behavior is probably safer than making Wine setuid... Unfortunately the default behavior can only be set globally, so that leaves me with: 1) make installing the package cause the global change 2) the above idea 3) do nothing I'm not sure which is worse, although I know doing nothing breaks a lot of apps. The long term solutions are described at the bug however. It would be rather nice if there were a cap_sys_ptrace that were at least restricted to other processes owned by that user...
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 29/09/10 16:53, Scott Ritchie wrote: Unfortunately the default behavior can only be set globally, so that leaves me with: 1) make installing the package cause the global change 2) the above idea 3) do nothing I'm not sure which is worse, although I know doing nothing breaks a lot of apps. The long term solutions are described at the bug however. It would be rather nice if there were a cap_sys_ptrace that were at least restricted to other processes owned by that user... What do other packages that depend on ptrace do? In particular, what does strace do? I'd ask about fakeroot-ng, but it's in universe, and I'm the upstream maintainer (read - Debian), so I'm fairly sure that's just broken, but do have a look at that too. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 09/29/2010 07:53 AM, Scott Ritchie wrote: On 09/29/2010 07:12 AM, Alexandre Julliard wrote: Scott Ritchie sc...@open-vote.org writes: Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. I don't think that's a good idea. CAP_SYS_PTRACE allows access to any process, so it's a lot more dangerous than the standard ptrace checks that Ubuntu decided to break. Going back to the default behavior is probably safer than making Wine setuid... Unfortunately the default behavior can only be set globally, so that leaves me with: 1) make installing the package cause the global change 2) the above idea 3) do nothing I'm not sure which is worse, although I know doing nothing breaks a lot of apps. The long term solutions are described at the bug however. It would be rather nice if there were a cap_sys_ptrace that were at least restricted to other processes owned by that user... Actually there's a 4th option that I hadn't realized: apps can give up their own ptrace protection. So Wine can do that for all Wine apps. This should be fairly easy (details at bug report).
