Log in

SELinux and Fedora 9

« previous entry | next entry »
May. 15th, 2008 | 09:01 pm

So through a mistake of mine I've discovered an interesting behavior of SELinux on Fedora.  I do not know if this is the default behavior across all SELinux deployments.  It may just be a way the way the Fedora developers chose to approach the problem.

Before I mention the behaviour I'd like to mention why I insist on using SELinux.  While I'm sure I've read my fair share of complaints about SELinux from the Fedora and Linux user community at large, I still feel uncomfortable not running it.  Particularly on a system that I like to remotely log in through SSH.  I mean, this is the value of having a Linux system, being able to log in and continue work.  But I definitely have a need to secure it, anyway I can.

I'm by no means an expert on securing systems, but I do take the usual precautions that everybody else does.  I make sure my firewall is configured to block all but those needed ports, mainly SSH on all machines.  I also find it important to run something like denyhosts to parse through the secure log and block an IP that is trying to crack into the system.  And lastly, I'm careful with what I download.  I even have an anti-virus installed to parse those attachments people mail me, and make sure I don't send it to anyone else by accident.

Regardless, all this does not seem secure enough without running SELinux.  The whole idea being that SELinux can lock down a system from within.  Simple Unix access control cannot prevent a process from accessing areas that it should not be accessing by design.  Of course, if configured incorrectly it can only backfire on the user, because it prevents processes from accessing resources they require.  For example, in Fedora Core 6 I had to log in as root for a while in order to transfer music files to my MP3.  It was annoying at best, but only highlighted some of the problems people were experiencing.

I've been running with SELinux enabled by default since Fedora Core 6 and have only run into minor problems.  That is, until today.  SELinux did the unthinkable.  It prevented the system logger from accessing the system logs.  It prevented X.org from accessing anything under the /var.  Any system process that needed to access bar was blocked.  The only way to run anything was to shut down SELinux.  I thought there was a mistake, and SELinux complained about /var having multiple specifications.  I found it odd, so I had it relabel the entire 500GB volume.  Took a few minutes, and the end result was the same. At each different relabel attempt I looked at the policy file, and it looked good, only one label for var.  So clearly, there was a mistake somewhere.

After countless relabels, and removing and adding the policy packages, I noticed it.  There was a nother file, a sort of dynamic file that was created.  This one claimed that /var was a home directory, and therefore no system process should store anything valuable there.  This was curious, because....oh...wait....oops.  That's right, at some point I needed a dummy user that I needed to test with for about a week or so.  I didn't want this user to have a login, so I assigned him a dummy home under /var/tmp.  At one point I had to log in as that user to set something up, and so it created a home directory at /var/tmp/username.  This went well for a few days until I updated my policy file.  Then somehow, that's when /var got relabeled.  The system noticed /var had a home directory, and designated the whole directory to be in user space.  This was the source of the whole problem.  After removing this dummy user, relabeling the entire drive just to be safe, I was back in business.

Only 3.5 hours behind on my work...sigh...  Lesson learned, quite well.  Ok, I'll never do it again.  But it was nice to learn about this feature, I'll look into it more now.

Link | Leave a comment | Share

Comments {0}