Share Next Entry
mmap_min_addr on SELinux and non-SELinux systems
There has been a lot of conversation about the difference in how the mmap_min_addr proteciton is applied on SELinux vs. non-SELinux systems and how these differences made it easier to exploit a recent kernel BUG on SELinux systems.  A number of people have claimed the SELinux made the system weaker.  It did, but in other ways it was still stronger.  I'm working to get the best of both worlds, but it isn't fair to claim a universal across the board weakening.

We, the SELinux team, made a decision to not require CAP_SYS_RAWIO (non techies can think of this as root, or uid=0) for mapping the 0 page.  Instead we have an SELinux policy specific permission for this operation, mmap_zero. We made the choice to not require one to be root because WINE needs to do this operation and (sadly) there are a number of users out there who run windows applications inside WINE.

Recently a kernel exploit was posted which works by mapping the 0 page, putting crafty info on that page, tickling a bug in the kernel, and winning (It is brilliant, as usual from Brad.)   To get that 0 page mapped on a non-SELinux system he had to find a busted suid application (he found pulseaudio) and get that to map the page for him.  Since SELinux systems don't require root, he didn't need to find a busted suid application, he just had to map the 0 page and tickle the kernel bug.

Now the claim comes out that SELinux systems are less secure than non-SELinux systems.  It's true, SELinux systems are weaker against authenticated logged in local users in this case.  But it's stronger against remote attacks.  What?  Yes, I agree completely that I need to strengthen the system against attacks from a malicious local user, but we do a much better job in this case if an attacker was trying to attack remotely.

On a non-SELinux system if the attacker was able to subvert any network facing daemon they won.  They just tickled do the same thing.  Take over daemon remotely, use pulseaudio to map the page, tickle the kernel bug, win.  But what happens on an SELinux system?  It doesn't work!  Take over the network facing daemon, try the pulseaudio trick, crap, didn't get the page.  Try to map the zero page directly.  Crap it didn't work.  Now what?  You win, they lose.  SELinux is stronger than non-SELinux.

This is because SELinux confines network facing daemons and doesn't give them permissions to map the 0 page.  It's not about root or non-root.  It's not about suid or non-suid.  It's about the SELinux domain not allowing the daemon to map the 0 page.  Yes, as an unconfined user you can map the page (and I'm looking at ways to fix that) but if your system is subverted remotely, you are likely much better protected with SELinux than without.

  • 1
howdy! thanks for the quality writeup; i added you as a friend to track anything more of this nature (most friend requests i get these days are spam).

Response from the exploit author

These are not my comments, they are the comments of Brad Spengler, the author of the really cool exploit I mentioned. He commented off of the blog, but gave permission to post his comments here.

First off, of all people/companies, Red Hat surely knows that stolen SSH credentials or guessed passwords isn't an esoteric entry vector.

NX+ASLR by itself is enough to deter someone from trying to inject a kernel exploit like this one within a network-facing process. The thing that does the most to keep a process compromised by memory corruption bugs from doing things it shouldn't is the SELinux feature a 3rd party developed, execmod -- basically PaX's MPROTECT feature (remember when Ingo argued against it?)

Second, it's a little disingenuous to try to prop up the security of SELinux by bringing up the Wine issue. How many webservers do you know of that run X and Wine? The real entry vector here is webservers (say with some vulnerable php / SQL injection bug) or other multi-user machines, not desktops where people would be running Wine (as a multi-user desktop with Wine would almost certainly involve some sort of physical access as well).

So in the cases where the exploit would have been actually used, by default, SELinux removed security that would have existed had SELinux been disabled.

And from reading Dan Walsh's blog, it looks as though the problem is quite a bit larger and won't be remedied fully anytime soon because
1) There still hasn't been a CVE for it yet, which demonstrates from Red Hat's end that this isn't important to them
2) Dan Walsh gave the command for all exploit writers to use to be able to mmap at 0 even if unconfined_t isn't allowed to do it in the future
3) He's also said that RHEL5 by default will continue to allow unconfined_t to mmap at 0 for compatability purposes.

Though I believe based on the current patch submitted to LKML, 2&3 will only apply when mmap_min_addr is disabled (though then the compatability argument doesn't make much sense, as users may be expecting to be able to mmap there (since they've been able to for who knows how long -- I haven't seen anyone from Fedora or Red Hat quantify this yet) and with the new kernel they'll be unable to without disabling mmap_min_addr).


The pulseaudio/personality trick

FYI, the pulseaudio/personality trick didn't come from Brad but from Tavis Ormandy and Julien Tinnes

Re: The pulseaudio/personality trick

I have never read something like this.
Great stuff!

  • 1

Log in

No account? Create an account