On Saturday 07 January 2012 08:15:35 Bennett Haselton wrote: > On 1/7/2012 6:50 AM, Marko Vojinovic wrote: > > On Saturday 07 January 2012 05:39:15 Bennett Haselton wrote: > >> Apparently the marketplace favors hosting companies turning SELinux > >> off > >> because the failures it causes are too obscure and it causes too many > >> support headaches. > > > > Ignorance is bliss... ;-) > > > > A hosting company should certainly have SELinux turned on by default. A > > customer who doesn't know how to handle it should be told to RTFM. > > See what I wrote to John about "should-statements"... you can't change > human nature, but you can make better defaults. What do you mean by "better" defaults? Better for the user, or better for the hosting company? Better in terms of quality/security, or better in terms of ease of use? There is no obvious "better" default, IMHO. This is about trading security for convenience, and if a hosting company puts convenience before security, they are doing a lousy job. Turning off SELinux is a choice that should be done by the *customer*, not by the hosting company. I am still waiting for the day when SELinux will become completely mandatory, just as the owner/group permissions are today. ;-) > > Sometimes there is a message on stderr about "permission denied" or > > such. But in general every AVC denial is written in > > /var/log/audit/audit.log. There are also setroubleshootd and sealert, > > to help you "translate" the AVC denial into something more > > user-friendly, and suggest what to do about it. > > Yes, once you know that SELinux is the cause, the tools for diagnosing > what to do are pretty helpful. But what hosting companies care about -- > in terms of inconvenience to the user -- is that there's no easy way to > find out for the first time that SELinux is the cause of something not > working. > > Hence the idea for having SELinux send messages to the terminal saying > "SELinux blocked such-and-such". There's probably some better way. Well, when something gets blocked by iptables, that doesn't even get into a log, let alone interactive messages. An administrator needs to be intelligent enough to *guess* that the app doesn't work because some port might be closed by the firewall. That's even worse than the situation with SELinux, and nobody has ever "fixed" that one in decades. :-) I guess it could be easily implemented, though. All AVC denials are being communicated via dbus, and can probably be caught and sent to a terminal as well. Read man audispd and related stuff --- I guess one can customize the relevant log daemon to send messages to the terminal too, in addition to the log file. If you manage to customize it, send us the recipe, I guess it could be helpful for others as well. :-) HTH, :-) Marko