Would SELinux prevent that with the current policy?

[Christoph Höger]

> 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.

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20090719/614e91f2/attachment.sig>