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