[CentOS] SELinux and access across 'similar types'

Bennett Haselton bennett at peacefire.org
Sun Jan 8 01:35:11 UTC 2012


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



More information about the CentOS mailing list