danwalsh


Dan Walsh's Blog

Got SELinux?


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

/etc/resolv.conf
/etc/mtab
/var/run/utmp
~/public_html
~/.mozilla/plugins/libflashplayer.so

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.

Dan

AppArmor

(Anonymous)

2006-05-20 06:31 pm (UTC)

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.

No HTML allowed in subject

  
 
   
 

(will be screened)

You are viewing danwalsh