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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
