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