mmap_min_addr should be handled via CAP_SYS_RAWIO

[Kees Cook]

Binary package hint: dosemu

I would like to see wine and dosemu using filesystem capabilties to temporarily grant themselves CAP_SYS_RAWIO during start up to map the memory below mmap_min_addr, instead of requiring that the entire running system have their mmap_min_addr lowered.

[Kees Cook (kees)]

Implementing this would involve two halves: setting up the filesystem capabilities when the package installed (postinst most likely), and dropping the capability once the program had allocated memory.

Here is a quick example of how to mark an executable with a capability:

http://www.friedhoff.org/posixfilecaps.html#Examples%20-%20Substitution%20of%20suid-0%20privilege%20with%20POSIX%20Capabilities%20privilege

They use numeric values, but it may be more readable to use text version:

 sudo setcap cap_sys_rawio=ep low-mmap

(setcap is in libcap2-bin)

Part 2 involves dropping the capability:

 http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/daemon/caps.c;hb=86dee05aec330a0c2886c0327712153793ca46c4

the pa_drop_caps and shows how to drop capabilities, and pa_have_caps shows how to test for a specific capability. (In the example's case, CAP_SYS_NICE.)

[Kees Cook (kees)]

(sorry, lost some context for my setcap paste: "low-mmap" is the program I was setting capabilities on. "cap_sys_rawio" is the textual version of the capabilities.)

[Scott Ritchie (scottritchie)]

Background:

In order to work around the mmap_min_addr setting introduced a while back that breaks Wine, many Wine packages now install conf files to /etc/sysctl.d/ that disable mmap_min_addr entirely. This reduces security of the system, as any kernel null pointer dereference bug can root the machine. One such bug was found to be open for 8 years.

This launchpad bug gives hints at what we need to do to implement this within Wine properly.

----
From Launchpad:

I would like to see wine and dosemu using filesystem capabilties to temporarily grant themselves CAP_SYS_RAWIO during start up to map the memory below mmap_min_addr, instead of requiring that the entire running system have their mmap_min_addr lowered.

Implementing this would involve two halves: setting up the filesystem capabilities when the package installed (postinst most likely), and dropping the capability once the program had allocated memory.

Here is a quick example of how to mark an executable with a capability:

http://www.friedhoff.org/posixfilecaps.html#Examples%20-%20Substitution%20of%20suid-0%20privilege%20with%20POSIX%20Capabilities%20privilege

They use numeric values, but it may be more readable to use text version:

 sudo setcap cap_sys_rawio=ep low-mmap

(setcap is in libcap2-bin)

Part 2 involves dropping the capability:

 http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/daemon/caps.c;hb=86dee05aec330a0c2886c0327712153793ca46c4

the pa_drop_caps and shows how to drop capabilities, and pa_have_caps shows how to test for a specific capability. (In the example's case, CAP_SYS_NICE.)

(sorry, lost some context for my setcap paste: "low-mmap" is the program I was setting capabilities on. "cap_sys_rawio" is the textual version of the capabilities.)

[Dan Kegel (dank)]

Here's the link: https://bugs.launchpad.net/bugs/401950

[Juan-lang (juan-lang)]

This qualifies as an enhancement.

[Dmitry-codeweavers (dmitry-codeweavers)]

> In order to work around the mmap_min_addr setting introduced a while back
> that breaks Wine...

Wine has a workaround for that since a lot of time, there is no need
for any fix.

[Scott Ritchie (scottritchie)]

Are you saying that if I remove the disabling of mmap_min_addr entirely
from the packaging Wine will continue to function as before? Do we no
longer need the DOS memory area at all?

[Alexandre Julliard (julliard)]

(In reply to comment #4)
> Are you saying that if I remove the disabling of mmap_min_addr entirely
> from the packaging Wine will continue to function as before? Do we no
> longer need the DOS memory area at all?

No, of course we need it. Though I'm not convinced that making Wine CAP_SYS_RAWIO is really safer than setting the mmap_min_addr to 0. It would need testing to see how early we can drop the capability, but if we have to load the DOS subsystem first then it's the same as not dropping it at all.

[Dan Kegel (dank)]

Maybe we could make

[Dan Kegel (dank)]

sorry, clicked 'save' instead of 'power off' :-)

[Scott Ritchie (scottritchie)]

I thought the security of CAP_SYS_RAWIO rather than mmap_min_addr wasn't to make Wine more secure, but to make the system more secure when Wine isn't running. The kernel bug above, for instance, was exploitable by non-wine programs if the user merely had Wine installed.

[Alexandre Julliard (julliard)]

(In reply to comment #8)
> I thought the security of CAP_SYS_RAWIO rather than mmap_min_addr wasn't to
> make Wine more secure, but to make the system more secure when Wine isn't
> running. The kernel bug above, for instance, was exploitable by non-wine
> programs if the user merely had Wine installed.

Yes, but it doesn't make much difference, because all you have to do is to wrap the exploit in a DOS binary and run it with Wine. Either way, if Wine is installed you can exploit the bug. Dropping the caps wouldn't really help either, since you can't distinguish a malicious DOS app from a legitimate one. The only way is to not support DOS apps at all.

[Dan Kegel (dank)]

It matters a tiny bit. It might be harder to exploit the
bug remotely if you have to inject a call to wine
into Apache via a buffer overrun, say.

[Scott Ritchie (scottritchie)]

Moreover, a system could be secured using things that prevent arbitrary processes from invoking Wine (using, say, App Armor). So an exploit on one of those won't necessarily go all the way up.

[stop (whoopwhoop)]

On all the machines that have wine installed cat /proc/sys/vm/mmap_min_addr returns 0.
Shouldn't this bug be marked as high or critical as this seems to be exploitable?
http://www.h-online.com/security/news/item/Root-exploit-for-Linux-kernel-published-742541.html

[Kees Cook (kees)]

I think CAP_SYS_RAWIO is the wrong way to handle this, actually. This still leaves Wine able to use the 0 page, which is what needs to be avoided.

[Austin English (austinenglish)]

This is your friendly reminder that there has been no bug activity for 1 year. Is this still an issue in current (1.3.29 or newer) wine?

[Scott Ritchie (scottritchie)]

Still an issue, still not important enough to spend time on.

[Dan Kegel (dank)]

At some point, once wine's working really well, security will
increase in importantce.

[lemonnier (p-lemonnier1)]

I realy dont know if the problem is solved with the new instable dosemu
1.4.0 + svn 2010-1
but I am realy satisfy with this version.
Sincerely
Patrice Lemonnier
Le samedi 01 octobre 2011 à 20:09 +0000, Austin English a écrit :
> This is your friendly reminder that there has been no bug activity for 1
> year. Is this still an issue in current (1.3.29 or newer) wine?
>

[Marcus Meissner (marcus-jet)]

should not be an issue anymore, as we run DOSBOX for dos programs now?

[Scott Ritchie (scottritchie)]

Indeed, letting dosbox take care of it puts the problem out of our hands.

I'm a bit confused as to how dosbox is able to run apps without the same privilege escalation, though.

[Marcus Meissner (marcus-jet)]

dosbox runs a full cpu emulation, so it does not need page 0 mapped.
(similar thing is done in dosemu in the current Ubuntu package btw)

you should probably drop the sysctl mmap_min-addr=0 setting from the Ubuntu wine packages before ubuntu security notices ;)

[Austin English (austinenglish)]

UPSTREAM seems appropriate to me.