problems with tmpfs and relabeling

[Stephen Smalley]

On Tue, 2006-04-18 at 10:08 -0400, Bill Nottingham wrote:
> I'm currently working with the stateless code, which mounts the root
> filesystem read-only, moving various things that need to be read-write
> to tmpfs bind-mounted in the appropriate location.
> 
> This initially runs afoul of policy, and I need to write my own
> policy that allows you to mount on top of /etc/resolv.conf (standard
> targeted policy doesn't like that for some reason. :) )
> 
> However, relabeling the files then fails - for each type that I'm 
> putting on tmpfs, I need to add:
> 
> allow <type> tmpfs_t:filesystem associate;
> 
> before relabelling works.
> 
> This seems strange - is this something that should be fixed in 
> the stock policy, or should I just carry this in my own module?

One option is to use a fscontext= mount option to change the security
context associated with the filesystem/superblock object to match your
usage, e.g. making it fs_t like a conventional filesystem rather than
tmpfs_t.  e.g.
	mount -o fscontext=system_u:object_r:fs_t:s0 ...

The other option is to allow the associations as you suggest above, but
then this would affect all tmpfs filesystems.  The associate check is
intended to allow the policy writer to enforce a separation of data
between filesystems, so that certain kinds of data can only exist in
certain filesystems.  However, it isn't truly being applied to achieve a
security goal in the example policy at present.  As an example, you
might want to prevent entrypoint executable types from ever existing
in /tmp.  Effectively applying such restrictions would typically require
both proper use of the associate check and use of fscontext= mounts to
individually assign filesystem contexts to particular filesystems.

-- 
Stephen Smalley
National Security Agency