[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!