For the record, I've always been of the opinion that SELinux was a great idea, and it would be incredibly useful. I personally think there are just too many moving parts on the average server (much less desktop) to properly define
everything processes on the system are allowed to do.
Over the last couple of days, I helped a client set up new nameservers. The client in question is a university (a small one, but still...), so, as nameservers go, theirs are fairly high-volume.
To make a long story short, we wanted to go nuts with locking down these nameservers, so I left SELinux enabled, installed bind-chroot, etc. I had one real problem... SELinux wouldn't let me mount a separate filesystem at /var/named. Once I figured out this was happening and found the audit message in dmesg, I ran audit2why and got a somewhat helpful explanation and suggestion for a solution. Still, I can't help but feel like it's a bug that I can't mount a filesystem there...
Other than that, things went pretty smoothly. I went to the trouble of making sure all the config files, zone files, etc. were all labelled properly, which was a little painful, but once I figure out how, it wasn't all that bad. I just had to train myself to do "ls -laZ" instead of just "ls -la" to verify things. I even wrote a little script to reset permissions, owners, and labels all at once. It went something like this:
#!/bin/sh
usage() {
echo "Usage: $( basename $0 ) --reference=RFILE file1 [ file2 [...] ]" >&2
exit 1
}
if [ $# -lt 2 ] ; then
usage
fi
chown "$@" || usage
chmod "$@" || usage
chcon "$@" || usage
(My thanks to whoever decided that all three of those commands should have a "--reference=RFILE" option. :-)
The SELinux tools are pretty decent now, but this little exercise pretty much just reinforced my opinion that SELinux is only useful if the sysadmin is willing to invest some time in setting everything up properly.
I hate to be negative... Seriously though, I still see software installation instructions that tell users to "chmod 777" some directory to make things work. (The last time I saw that, it was instructions for some software that was distributed as an rpm. It was sad on so many levels...) Software developers generally suck (IMHO), and most people who do system administration aren't much, if any, better. And that's with our, what, almost 40-year-old security infrastructure? Users aren't even waiting to have a problem... They just immediately turn off security. It's no wonder that most Fedora troubleshooting tips start by having the user disable SELinux.
Anyway, I can't decide if I'm just whining here, if I'm trying to tell a story, or if I'm trying to make a point... I
think my point is not that SELinux is bad, but
we need to set expectations appropriately. It is a tiny bit unrealistic to expect our packagers to get everything to work right with SELinux. And that's the part we can control... The users just aren't going to get it, period. Maybe ever.
sigh
