On 1/7/2012 9:41 AM, Marko Vojinovic wrote: > 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. :-) Well, yes there would be fewer usability issues if it did send a message to the user. Although, a firewall is something that a user might be more likely to guess about, because firewalls exist on every OS and have for a long time, but SELinux is Linux-only and apparently only one some distros. > 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. :-) > I don't need it for myself, now that I know to look in the logs :) The point was to make it more discoverable for users who may not realize it's turned on and why their new server app isn't working. Bennett