Log in

No account? Create an account

Previous Entry Share Next Entry
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.


  • 1


Just found this and my first thought is "This is different to the AppArmor approach how?"

AppArmor restricts based on file paths. To deal with hard links it disallows their use in certain circumstances.

To make SELinux usable for normal people, you have written a daemon that sits around layering AppArmor file-path/hardlink like semantics on top of SELinux in a racey, hacky, inefficient way. I don't mean you write bad code, I just mean that it's a limitation of the approach (we already have way too many daemons sucking up memory for their stacks/heaps/bookkeeping).

Stuff like Flash Player being there is also quite a concern. This system plays nice with 3rd party software? I rather think not ... very worrying indeed. I also don't see why the kernel can't cope with file names if not file paths, so you could say "resolve.conf" in a directory of label etc_t.

One more comment...

Hello! ;)
hey... what crazy news!
what do U think about it?

You mentiond this is not to be used on MLS machines? what are the implications?


Child Safety Products

hello Dan,

Apart from entering the respective file or directory path in /etc/selinux/restorecond.conf, i preseume we need to add an entry to semanage table:
e.g. semanage fcontext -a -f -- -t tmp_t /root/example.txt

Only after this would the type transition occur from the old to the new customized type as given in the restorecond.conf file.

Please clarify the below:

As per the above explanation, i see an entry for public_html in restorecond.conf file but not in the output of semanage fcontext -l. I would therefore like to know from where is the default type (httpd_sys_content_t) taken and assigned to public_html directory.

Please clarify.


Re: semanage clarification

If you want to have a customized label for a file, you need to tell SELinux about it. You can either do this via the semanage command as you state or by building a custom policy module including a fc file

semanage fcontext -a -f -- -t tmp_t /root/example.txt


/root/example.txt gen_context(system_u:object_r:tmp_t, s0)

Contents in the home directory are special. This is because we do not know where the homedir will be. If you look in

grep public_html /etc/selinux/targeted/contexts/files/file_contexts.homedirs
/home/[^/]*/((www)|(web)|(public_html)|(public_git))(/.+)? unconfined_u:object_r:httpd_user_content_t:s0
/home/pwalsh/((www)|(web)|(public_html)|(public_git))(/.+)? staff_u:object_r:httpd_user_content_t:s0

genhomedircon generates this file out of


If you want to customize content in the homedir you need to install a custom policy with a file contents like

HOME_DIR/example.txt -- gen_context(system_u:object_r:tmp_t,s0)

  • 1