[wplug] Who benefits from SELinux?

[Pat Barron]

To *vastly* oversimplify (because it's sufficiently complicated that I 
don't totally understand it myself...):  It lets you create rules that 
define what programs are allowed to perform what operations - things of 
the form, "this program (or things tagged with this tag, or users with 
this role, etc...) can write to files in this directory", or "this 
program can bind sockets to these ports".  So it lets you define your 
security with much finer granularity than just "root" or "not root" - 
restrictions defined in these rules even apply to root.

Where it always seems to hose me up is with things that aren't packaged 
for the distro I'm using.  Package install/configure scripts usually 
create SELinux rules (if necessary) to let that package do the things it 
needs to do, and those rules are installed at the time the package is 
installed.  If building something from source, that doesn't usually 
happen.  So you go into your source tree, type "make install", start the 
newly installed service - and it craps out because it can't write to a 
file in some directory, or can't bind to some particular port (even 
running as root).  The most *infuriating* thing is when a service does 
something "special" the first time it runs (like creating and populating 
a database, or something similar), and it fails in the middle of that 
initialization because SELinux stopped it from doing something - then 
you go to start it again, and it doesn't work because it's initial setup 
never finished, but it knows the initial setup was "supposed" to have 
been done so it doesn't try again.  In that case, I usually find that 
the path of least resistance is to uninstall and reinstall whatever it 
is, after adding the right SELinux rule to allow it to do whatever 
failed - and hoping it doesn't later hit another instance where SELinux 
makes something fail, and you get to do this process all over again...

Now, I know there are really good reasons why you might want to do this, 
especially on Internet-facing servers that might face attack, and where 
programs running on them could be used as malware vectors.  So, for 
instance, no matter what, you know for sure that the mail daemon under 
no circumstances should be able to write to /etc/passwd - there is 
simply no reason that would be a valid thing for a mail daemon to do.  
So you can have an SELinux rule that will stop any attempt it might make 
to do so, even if the mail daemon is running as root.  But for most 
typical uses, I've just never understood why so many current distros 
install and enable SELinux by default.  For home users (and even many 
non-home users), the machines are unlikely to be in an environment where 
this kind of thing is important, and the primary effect of SELinux is to 
cause hard-to-diagnose errors, pulling out of hair, and other unpleasant 
phenomena...

I believe Red Hat and Fedora ship with SELinux rule sets that in theory 
let you create a (mostly) MLS-secure system, where different data has 
different classifications (like "confidential", "secret", "top secret", 
etc.), a user's (or process's) role defines what security clearance it 
has, things like "no write up, no read down" are implemented, etc...  
I've always wanted to try that - just as an experiment, to see what 
would happen, since it's not clear to me how any Unix-like system could 
operate in a reasonable way under MLS security constraints....  ;-)

--Pat.

On 04/10/2012 4:14 PM, Greg Akins wrote:
> On Tue, Apr 10, 2012 at 4:08 PM, Matthew Zwier<mczwier at gmail.com>  wrote:
>> Never saw the need for it on top of hardened Gentoo for a server.  May
>> be different for a machine with a large number of users, though, like
>> a cluster head node.
>>
> Can anyone explain what exactly SELinux is?  I always thought it was a
> configuration standard and a set of tools.   As such, I would have
> thought that having SELinux installed might be synonymous to a
> "hardened" system.
>
>