| |||||||||||||
Not reallyNot reallyPosted Jul 10, 2008 8:50 UTC (Thu) by jschrod (subscriber, #1646)In reply to: Not really by khim Parent article: SELinux and Fedora No, the problem of that PostgreSQL denial was not that the admin was unfamiliar with SELINUX and that it doesn't work different than on plain Linux. The problem is actually many-fold, and can be nicely illustrated by the example that you cited:
(Log in to post comments)
Not really Posted Jul 10, 2008 13:39 UTC (Thu) by kh (subscriber, #19413) [Link] I have been thinking that the traditional Unix security model has strength because of its simplicity: 1) It is easy for any normal sysadmin to understand 2) It is easy to audit 3) It is easy to edit Maybe there is a wealth of tools and custom scripts out there for selinux that I am not aware of, but I do not think they exist because selinux is too difficult to completely conceptualize. I also do not understand why any type of selinux (or any other security) error should be anything other than noisy and verbose, especially when installed by default on a desktop. Does selinux give silently logged errors that should be ignored by an average user?
Not really Posted Jul 10, 2008 14:20 UTC (Thu) by jschrod (subscriber, #1646) [Link] I agree with you mostly. Concerning the error messages, in my experience, it is even worse: Not only are they not sensible for an average desktop user, they are not even sensible for an experienced sysadmin user! Therefore, using SELINUX on a desktop system is doomed to cause great pains for the user community. (It bothers me only on an abstract level, though. On the desktop, I use SUSE... :-)) But I don't think that the traditional Unix security model (easy as it is) can survive in the long run. In our Internet-connected age the environment and associated threat model got more complex, and such simple solutions won't be adequate in the long run. But I don't have any idea how one can teach compartimentation and MAC to run-of-the-mill sysadmins and end-users who are forced to be their own sysadmins.
Not really Posted Jul 10, 2008 18:03 UTC (Thu) by dpquigl (subscriber, #52852) [Link] 2) I would like to have seen the error that he was getting from postgres but I have a feeling if you ran it through one of the several tools it would have become apparent that postgres didn't have permission to follow symlinks. However, this stems from needing to know that there is a difference between symlinks and directories so even if it was clear in the message it would need further explanation. 3) I agree that SELinux documentation is lacking at the moment but there are several efforts currently going on to work on this. I have been preparing a series of tutorials and presentations for educating people about the security model SELinux implements and how to configure a machine in non-standard ways such that it still works with SELinux. Also there is now someone working full time to generate documentation for SELinux. 4) We have seen this complains come up quite a few times and we can't figure out where it comes from. Have you had personal experience with someone in the community treating you this way? When I first started learning about SELinux I had many questions and the community was very helpful and didn't make me feel stupid for asking them. If you have specific examples of this I'd be glad to see them. It is possible that this might be a residual complaint from the early days of SELinux that has hung around like some of the other complaints people have about SELinux.
Not really Posted Jul 10, 2008 18:12 UTC (Thu) by dpquigl (subscriber, #52852) [Link] I forgot to mention, if there is anything you would like to see in the SELinux documentation feel free to send suggestions to the mailing list and we will see about integrating them into the documentation list.
Not really Posted Jul 15, 2008 8:24 UTC (Tue) by mauvaisours (guest, #6130) [Link] I've been hurt by SELinux some years ago, when installing a server that I needed for a quick demo. At that time, I was only semi-aware that RH had turned SELinux on by default. So when things got wrong (from my point of view), I was completely baffled. The big black point of SELinux is that it does not show up in standard commands [ls, ...], so that the message you get is "permission denied", but you have no way of knowing why. And the documentation was (is?) so thin on the subject that all I could do (at the time) was just shut it down, and as I was too busy, I never looked at it again, and I disable it on all new installs. So my guess would be : 1/ Write an extensive documentation 2/ Make people read that doc (it's not that hard. I would.) 3/ Include that documentation on standard distros. 4/ Turn SELinux on by default. It was done in the wrong order.
Not really Posted Jul 15, 2008 18:44 UTC (Tue) by nix (subscriber, #2304) [Link] Hah, I wish. It is *very* hard to get most people to read any documentation at all, generally because they don't care about SELinux (or any security system protecting against *potential* threats) until it causes problems, by which point things have already gone wrong. (If they're not running it they may suddenly start caring when they get rooted, but that, again, is too late.) Nobody knows how to resolve this particular dilemma :(
Not really Posted Jul 15, 2008 19:38 UTC (Tue) by mauvaisours (guest, #6130) [Link] I agree that nobody knows how to resolve this dilemna, but pushing a new undocumented security model to users is certainly not the way to go.
Re: Not really Posted Jul 11, 2008 16:03 UTC (Fri) by jmmc (guest, #34939) [Link] Also wanted to back up dpquigl in response to your #4 point... At absolutely NO point have I ever encountered a response about SELinux from anyone (lists, irc, etc) who was condescending to me or considered my inquires 'simple' or 'stupid'. I think this comment is overly harsh in that regard. Heck, I've learned quite a bit just in the 50+ or so comments here today - thanks again to OFE (Our Favorite Editor, JC for even keeping this topic important, which it is, imho). Lastly, I support SELinux 'policy ON by default'. Kudos to RedHat for being persistent on this matter. I was trained that good policy on *NIX was always 'deny by default, allow by approved request' from well before the SEL era...and default SEL is violating that principle ?...how ?
|
|||||||||||||