> 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.
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
