Hi,
after looking at: http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html
I wondered if SELinux would not be the right answer to those re-exec exploits. I guess that pulseaudio should run as something like pulseaudio_t which has all caps it needs. Re-exec should not change that as pulseaudio does not need any transformation of context.
So short question: Does it work that way?
On 07/16/2009 10:50 PM, Christoph Höger wrote:
Hi,
after looking at: http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html
I wondered if SELinux would not be the right answer to those re-exec exploits. I guess that pulseaudio should run as something like pulseaudio_t which has all caps it needs. Re-exec should not change that as pulseaudio does not need any transformation of context.
So short question: Does it work that way?
Read this
http://blog.namei.org/2009/07/18/a-brief-note-on-the-2630-kernel-null-pointe...
Rahul
On Sun, 2009-07-19 at 15:21 +0530, Rahul Sundaram wrote:
On 07/16/2009 10:50 PM, Christoph Höger wrote:
Hi,
after looking at: http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html
I wondered if SELinux would not be the right answer to those re-exec exploits. I guess that pulseaudio should run as something like pulseaudio_t which has all caps it needs. Re-exec should not change that as pulseaudio does not need any transformation of context.
So short question: Does it work that way?
Read this
http://blog.namei.org/2009/07/18/a-brief-note-on-the-2630-kernel-null-pointe...
Rahul From what i heard there were two bugs one in pulseaudio and one in kernel.
When operating in a unconfined domain one (obviously) could exploit the kernel without using pulseaudio To me this makes perfect sense as in my view unconfined_t is a domain for the SElinux exempt. SELinux is built-into the kernel and so in a SELinux environment the kernel will always be a vulnerable spot.
In my environments this exploit did not work. I only use unconfined_t for a privileged secondary domain for myself. For all other users i use strict user domain and role based access control (strict privileged secondary domains)
From what i understand there also was a bug in SELinux policy in a
function that disallows mmap for unconfined_t. allow_unconfined_mmap_low, However this boolean is disabled by default anyways. (as i would expect in a unconfined domain)
So in my view this issue is not really selinux related. SELinux does prevent it from happening if you configured is strict. If you map users to unconfined environments then obviously you have a problem but thats not selinux fault in my view.
What this issue does show, and i think jmorris touched on this, is that, and i have said this many times: writing policy is one thing, but maintaining policy is another. is that policy needs to be reviewed once in a while. So that these bugs get found before they get " exploited".
But again, for my environment, SELinux did its job. and to me this is another victory for SELinux.
But for those that use the policy defaults i am sorry because they are (more) vulnerable to this issue,
SElinux is two parts: The framework and policy. In this case policy is not optimal.
Back in f2 we used a strict policy but it was no success because the policy wasnt mature enough. So targeted was designed, Now strict policy is more mature. maybe its time to move back to strict again. Or atleast use strict by default and let users optional map to unconfined_t.
So long story short: in my view SELinux is the answer. This current targeted-policy model may not be the right answer. (atleast not if we want to protect/restrict users by default)
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
But for those that use the policy defaults i am sorry because they are (more) vulnerable to this issue,
More? In what way can SELinux make you _more_ vulnerable? LSM are stackable, right? So basically all SELinux could do is restrict access and not allow access that already is denied by the dummy LSM, or not?
Back in f2 we used a strict policy but it was no success because the policy wasnt mature enough. So targeted was designed, Now strict policy is more mature. maybe its time to move back to strict again. Or atleast use strict by default and let users optional map to unconfined_t.
So long story short: in my view SELinux is the answer. This current targeted-policy model may not be the right answer. (atleast not if we want to protect/restrict users by default)
AFAIK Dan Walsh blogged some time ago about confining firefox, because that is where we loose the linux security advantage: In the userland. (Ever tried to read your private ssh key with firefox? Combine that with one of the latest exploits and *bang* network open to everyone) You could of course make a strict userland policy, but who should be in charge of maintaining? Upstream? Package maintainers? Someone special? Think of all those binaries you would need to confine, that seems like way too much work to be done.
On Sun, 19 Jul 2009, Christoph H?ger wrote:
But for those that use the policy defaults i am sorry because they are (more) vulnerable to this issue,
More? In what way can SELinux make you _more_ vulnerable? LSM are stackable, right? So basically all SELinux could do is restrict access and not allow access that already is denied by the dummy LSM, or not?
Usually, but in this case, the problem is that SELinux (and this could happen to any LSM, really) allowed more access than the configured default.
We want to be able to use MAC policy to allow applications to mmap low memory. There does not seem to be a really great solution which avoids the problem of then allowing more access than would otherwise be allowed.
Consider, though, that you you wanted to run wine on a standard system, you would disable mmap_min_addr entirely for everything on the system. Most people will probably not need to do that and have it set at the normal value.
Perhaps what we should do is never allow SELinux policy to reduce the protection level here, which would mean that if someone wants to allow an app to mmap low memory, they have to:
a) disable protection globally via the sysctl b) then depend entirely on SELinux to enforce it except for domains with the mmap_zero permission
So, IOW, the SELinux permission won't have any effect until the admin removes the "DAC" control globally.
- James
On Sun, 19 Jul 2009, Dominick Grift wrote:
From what i heard there were two bugs one in pulseaudio and one in kernel.
When operating in a unconfined domain one (obviously) could exploit the kernel without using pulseaudio To me this makes perfect sense as in my view unconfined_t is a domain for the SElinux exempt. SELinux is built-into the kernel and so in a SELinux environment the kernel will always be a vulnerable spot.
Yes, although SELinux should not reduce the security of the system vs. the default. This is the core issue from the SELinux POV.
In my environments this exploit did not work.
The exploit depends on having non-default permissions on /dev/net/tun, or running as root, which was not made clear in the video or code. It seems that udev on at least F9 changes the permissions on the device, so beware.
It's still a bug for SELinux, though, because it is designed to protect against DAC weaknesses.
What this issue does show, and i think jmorris touched on this, is that, and i have said this many times: writing policy is one thing, but maintaining policy is another. is that policy needs to be reviewed once in a while.
Well, I think the underlying problem is that it should not be possible for a policy writer to make the system less secure. It needs to be more robust, so that policy errors at least default to the standard DAC level of protection.
- James
selinux@lists.fedoraproject.org
-
Christoph Höger -
Dominick Grift -
James Morris -
Rahul Sundaram