[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!
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
