[CentOS] SELinux - way of the future or good idea but !!!

Wed Dec 8 02:28:22 UTC 2010
Marko Vojinovic <vvmarko at gmail.com>

On Tuesday 07 December 2010 23:29:44 Les Mikesell wrote:
> On 12/7/10 1:45 PM, Marko Vojinovic wrote:
> > And it isn't really rocket science. It's just an extension to the
> > existing classical permissions system --- it works in analogous way,
> > just with greater flexibility and power. If you know how to understand
> > and use file permissions, you will easily grasp all about SELinux.
> No, it doesn't have much in common with the standard uid/gid based
> permissioning system.

Of course, it's different, but the idea is the same --- both a process and a 
file have a set of labels (flags, owner, group, SELinux context). On each access 
attempt, these labels are checked for "compatibility" one by one (old 
permissions first, SELinux policy second). If all the flags are "compatible", 
access is allowed. Otherwise it is denied.

On this elementary descriptive level both DAC and MAC systems appear pretty 
identical. Of course, if you go into the details, they're quite different, 
SELinux offering way more flexibility in policy creation and enforcement, but 
the typical admin doesn't actually need to be aware of these differences --- if 
the system denies access to something, you should first try to understand why 
and maybe adapt to the proper service usage/configuration. And if you are 
absolutely sure that this access should be allowed,  you can always just go 
and adjust the labels (flags, owner&group, context) to make it work. Use chmod, 
chown, chgrp, chcon to fix whatever needs fixing. Once that is done, you should 
use semanage to make the chcon changes persistent, if you wish. From an admin 
POV, absolutely no operational difference.

In the vast majority of cases, the admin typically doesn't need to know any 
more than this, and SELinux can be regarded just as a more intricate set of 
labels, in addition to the usual traditional ones.

> > 5) disable SELinux and be ignorant about security.
> > 
> > If you choose 5), feel free to also disable iptables, log in as root all
> > the time, and make sure that the root password is clearly visible on the
> > company website. Why bother with all that stuff, anyway? ;-)
> I think you've missed the point that 'all that stuff' (being traditional
> unix security mechanisms) are not all that insecure.  It is only when you
> get them wrong that you need to fall back on selinux as a safety net.  
> And if you can't get the simple version right, how can you hope to do it
> right with something wildly more complicated?

My comment was ironic --- the point is that if you decide you don't need one 
security layer, why don't you decide that you actually don't need another, and 
another, and... all of them?

Disabling SELinux is the same type of decision as disabling the firewall --- 
it's there to protect you, yet you don't know how to properly configure it and 
use it, furthermore you don't want to bother to learn, so you simply disable 
the thing that's getting in your way and preventing you from doing what you 
want (which is typically very stupid securitywise, but ignorant don't care 

And I could argue that iptables configuration is at least equally complex as 
SELinux configuration. They're even similar in design --- one filters network 
access, the other filters file access. One has a set of rules (tables) to 
determine what is allowed, the other also has a set of rules (policy) to 
determine what is allowed. In order to tweak one you need to read and 
understand man iptables, while in order to tweak the other you need to read 
and undestand man semanage (restorecon is quite trivial once you grasp this). 
One comes with a reasonable default configuration, the other also comes with a 
reasonable default configuration.

The only major difference I see is that setroubleshoot will visibly yell at you 
if something generates an AVC denial, while iptables will silently do its 
thing and let you ponder on why your favorite app doesn't want to establish a  
connection... I wonder if there is an analogous alert tool that would wreck 
havoc on the screen when some packet is dropped by iptables, and telling you 
the exact syntax for the iptables command you need to execute if you want to 
allow that access. Come to think of it, such a tool might actually be useful 
in some cases. :-)

So I would expect the admin who disables SELinux by default to also disable 
the firewall by default --- they both get in your way, especially if you use 
some 3rd party software that requires both of them to be custom-configured.

But I don't see anyone suggesting that disabling the firewall would be a good 
idea, so why disable SELinux then? Once you go down the "I don't need this 
security layer" road, where do you stop, and why? My advise is --- don't even 
start going down that road, rather invest some time and learn how to use 
SELinux, just as you have invested some time in the past and learned how to 
use chmod, chown and iptables.

Best, :-)