April 3rd, 2006

Introducing restorcond

When I first started working on SELinux, one of the hardest things to deal with was maintenance of the file context. If a file is created in a directory and it needs a different file context than the containing directory, userspace can have problems.

As an example. Many confined domains need to be able to write /etc/resolv.conf. We do not want to allow these domains to be able to write to /etc (etc_t), since critical files like /etc/passwd also have that label. So we need a different file context (net_conf_t). So we write a file_transition rule in policy, that says if XYZ domain creates a file in etc_t, then the kernel should label it net_conf_t. dhcpc and NetworkManager have rules like this. The problem is that these are the not the only tools that write these files. Many admins use tools like sed, awk, perl, python, vi, emacs ... Obviously we can not write policy rules for any of the command tools. Some tools attempt to maintain the context, like vi.

The kernel guys would not put any userspace constructs into the kernel such as file paths, so we could not put a rule in that says if you create a file named /etc/resolv.conf label it net_conf_t. So we looked for a solution for the most common problems we were seeing.

I decided to build a tool called restorecond. This tool takes a list of files /etc/selinux/restorecond.conf and watches for their creation. It uses inotify to monitor the parent directory for file creation/rename. If one of the files in the list gets created, it instantly relabels the file to the correct file context.

This tool not only watches the config file but if you add an entry like ~/public_html, it will watch for the creation of this directory in all logged in users homedirs. The way it does this is to watch for users logging on to the system and then putting a watch on there home dirs.

restorecond raises some security concerns, in that it will restorecon a file under control of the user. One of the things we guard against, is hard links. So if the user created a hard link between /etc/shadow and ~/public_html, he could get restorecond to label /etc/shadow as httpd_sys_config_t. So we check the files to make sure it has only one link or is a directory.

So one other comment about this tool is the possibility of a race condition, and that does exists. So this tool should really not be used for security sensitive data.

Currently we have it watching.


Policy still exists for all confined domains to create the files without the race, but if the files get created with the wrong context restorecond will fix it within microseconds.

This tool should not be used on an MLS machine, (The admins need to be more carefull). But for a targeted machine it can help with usablility.