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

Wed Dec 8 21:41:57 UTC 2010
Warren Young <warren at etr-usa.com>

[I'm guessing from the dozens of quoted lines per reply that many of 
y'all aren't as lucky as I am.  I have a threading email reader with 
backing store, so I can go back and read past messages in a thread if I 
need more context than a brief quote can provide.  I have been so lucky 
since the mid 90's, but I do realize that technology moves slowly into 
some parts of the world.]

On 12/8/2010 9:20 AM, David Sommerseth wrote:
>
> The basic SELinux stuff which most users
> need to know about *isn't* as hard as people want it to be.  Really!!

I'd say that any tool that reports errors with GUIDs and needs a 
background wizard process to turn those GUIDs into prose the system 
operator *might* understand is overly complex.

Security is never absolute.  It is a balance between convenience and 
protection.  I accept quite readily that some will choose not to put up 
with the level of inconvenience SELinux imposes.

For a similar example, observe how little-used ACLs are, especially in 
the *ix world.  On Windows, where they're the only game in town, observe 
instead how rarely ACLs get changed from their defaults.

> Otherwise, don't make SELinux more complex than what it really is.  The
> core concept is basically a different way how to restrict access for
> processes - on the same level as chmod, uid/gid and ACLs does on files.

The trick is to make the resulting system work in obvious and intuitive 
ways.  The original Unix file permission model is one of the many bits 
of genius in Unix that contributed to its success.

You'll observe by contrast that SELinux hasn't swept the Linux world, 
and has yet to escape into the commercial and BSD worlds.  SELinux is 
not not an obviously-good thing, the sort of thing that spreads 
everywhere, quickly.

Some examples of nonintuitive SELinux behavior from my own experience:

- You install an RPM from a third party who provides a newer version of 
something that ships with the OS.  Consequently, the OS has filesystem 
labels on directories used by the new RPM which are not appropriate for 
the newer version of the package.  It fails to run.  You complain on the 
package provider's mailing list, and they say it works for them.  Later 
you find you need to run some obscure command to force the filesystem to 
relabel all these files because the package provider has SELinux turned 
off on their build and test systems and so doesn't ship their RPM with 
relabeling as part of the postinstall script.

- You install a binary library from a third party, and the program using 
it fails to run.  Why?  A required label (textrel_shlib_t) wasn't added, 
as happens automagically when you install libraries from an RPM instead. 
  (Oh, and good luck remembering that obscure rule next time.  I install 
third-party binary libraries this way maybe once a year, too rare to 
commit the rule to memory.)

- You're developing a web app, and the server-side tier connects to a 
back-end server (typical N-tier architecture) to do some work you don't 
want to do or can't do in PHP/Python/Perl/Ruby/whatever.  Boom, you lose 
again, because the default httpd config prevents the web server -- or 
anything within that same process, like a web app -- from making 
outbound TCP connections, on security grounds.

- Same web app, but you make the silly mistake of wanting to install it 
somewhere other than /var/www/html.  (Which worked in all older systems, 
by the way.)  Oh, you silly boy!  Don't you know httpd mustn't be 
allowed to read served files from anywhere but that one directory? 
Boom, you lose again.

Don't bother telling me how to fix all these, I've worked around all of 
them.  I'm pulling them from a script I wrote specifically to apply 
these fixes to systems where we install our product.  I'd never remember 
them if I had to do it manually every time we ship a system.

/That/ is my point.  I could -- and sometimes do -- work around file 
permissions errors manually, quickly.  SELinux has a higher order of 
complexity compared to Unix file permissions, so the associated fixes 
don't fit into a small, easy-to-mentally-model framework.  Each fix 
therefore becomes a one-off that you have to write down in a document or 
script else you'd have to rediscover them with Google every time.

P'tui!