Andrew Farris wrote:
Jonathan Underwood wrote:
The problem is: setroubleshoot teaches average users that avc denials
come about due to bugs in selinux policy. If there was some massive
security problem right now on my machine causing avc denials I'd
probably react by filing a stack of bug reports. This is the
fundamental problem as it stands with SElinux. If it was working, we
would be in a situation where the first responce to an avc denial is
"OMG there's a security issue with something running on my machine, I
must fix that".
True enough, but that (trusting denials are legitimate breaches) is a
goal that is not necessarily here yet... while there are still bugs
being filed in policy you (or 'average users' such as me and most
rawhide testers) have very little chance of knowing which is which.
That doesn't mean it is not working... a security problem thats
generating denials is only a problem per se when you go and disable
selinux thinking 'its just a bug I can ignore these and let it happen'.
As long as a bug is filed, and your machine is still enforcing, and
someone hasn't found a way around the denials, either the policy will
change or Dan is going to post back to that bug report that what is
happening is definitely not going to be allowed by policy. Thats when
you go fishing for your security issue.
Or instead of you going fishing, the bug is recategorized and someone
else comes in to work with you on fixing the real problem (since odds
are we are packaging whatever it is that does have the issue).
Most people probably just go and disable it, assuming denials were
from something they were trying to do and a bug prevented them from
doing it. I think its very important that rawhide testers be using
selinux though because there is no way to prevent policy bugs from
getting to release (and the broad userbase from then disabling
selinux...) otherwise.
I still tell new linux users to disable selinux when they install. Its
just too much to explain to someone who is already in uncomfortable
territory.
--CJD
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
