On 04/01/2008, Andrew Farris <lordmorgul@xxxxxxxxx> 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. > Yep, exactly. And in fact that's exactly what's happening - a good example is a bug I filed against the SElinux policy which turned out to be another program leaking file descriptors. I worry though, because setroubleshoot suggests, amongst other things, running audit2allow to allow whatever behaviour prompted the avc denial. That's obviously very dangerous if you do it without knowing what you're allowing. > 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. > Agreed, certainly. j. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
