Once in a while I get this urge to use SELinux on some of the servers I manage, but almost always run in to something that puts me back enough to never finish the project. This time I managed to figure out the last few glitches. In the end, SELinux still has a really steep learning curve, so it's not for the impatient ones. Even though enabling SELinux in Debian has become a lot easier since the first time I tried to get things running, it's still just the tip of the iceberg. In Debian it is just a matter of installing the right packages and running a few commands, but that's just where the troubles start.

Most of the howtos focus on single user or shared installations where all users are created locally. Also most howtos fail to mention that you need to relabel files in certain cases.

One of the most annoying problem I ran in to was changing all non-system users away from the unconfined_u class. This is of course done like this (found here):

semanage -m -s user_u __default__

The problem here is that it changes the existing user as well and you start to get errors like these:

denied  { read } for  pid=32258 comm="bash" name=".profile" dev=dm-5 ino=185474 scontext=user_u:user_r:user_t:s0 tcontext=unconfined_u:object_r:unconfined_home_t:s0 tclass=file

The problem here is that the home directory for the user is still labeled for the wrong class. The fix is to relabel the home. Sadly this is something that you just need to know, it's not explained anywhere. At least I haven't found an explanation anywhere. Another good thing to do before you continue is to change the already existing user to the staff class. Staff class has a bit more relaxed security controls and you get to change the security roles (details here).

semanage login -m -s staff_u myuser
fixfiles relabel /home/myuser

This gets you a semi working setup, next problem usually is that some daemons are denied access to parts of your system. For me, this was postfix trying to access my home directory that was mounted over NFS. For such cases, you should persuade the maker of the module package to update the global policy if it's a common use case. Or you need to create a policy package that allows access to the given files.

The process itself is documented in the audit2access manual page. In general you should study the audit2why and audit2allow packages. The former tells you if there is an easier way to fix something (like enable a boolean) and latter will create the required policy lines. Only problem is to compile the policy and load it. The only problem here was to find the right tool and the right lines from the manual.

In general the SELinux learning curve is way too steep. It's a system that works pretty well once you learn all the tricks and start to completely understand the toolset. The community should continue working on lowering the bar for new users. There has been some major improvements since I first tried SELinux, so it's the right direction.

Fedora and SELinux
If you want to look at how easy it can be, look at say Fedora 11 + updates. It is pretty neat
Comment by neo Mon Jul 13 09:35:21 2009
Wow, i'm behind on comment moderation =)
Yeah, I've been given the impression that Fedora is one of the distributions that gets things right. Although, they did have a rocky start as well.
Comment by ressukka.net Wed Sep 2 09:52:26 2009
Comments on this page are closed.