Would SELinux prevent that with the current policy?

[Dominick Grift]

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-pointer-vulnerability/
> 
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list