Re: Security issues with local filesystem caching

[David Howells <dhowells@redhat.com>]

David Howells <dhowells@redhat.com> wrote:

> Some issues have been raised by Christoph Hellwig over how I'm handling
> filesystem security in my CacheFiles module, and I'd like advice on how to
> deal with them.

Having discussed this with Stephen Smally and Karl MacMillan, this is, I think,
the security model for CacheFiles:

 (*) There will be four security labels per cache:

     (a) A security label attached to the caching directory and all the files
     	 and directories contained therein.  This identifies those files as
     	 being part of a particular cache's working set.

     (b) A security label that defines the context under which the daemon
     	 (cachefilesd) operates.  This permits cachefilesd to be restricted to
     	 only accessing files labelled in (a), and only to do things like stat,
     	 list and delete them - not read or write them.

     (c) A security label that defines the context under which the module
     	 operates when accessing the cache.  This allows the module, when
     	 accessing the cache, to only operate within the bounds of the cache.
     	 It also permits the module to set a common security label on all the
     	 files it creates in the cache.

     (d) A security label to attached to the cachefiles control character
     	 device.  This limits access to processes with label (b).

 (*) The module will obtain label (a) - the security label with which to label
     the files it creates (create_sid) - by reading the security label on the
     cache base directory (inode->i_security->sid).

 (*) The module will obtain label (c) by reading label (b) from the cachefilesd
     process when it opens the cachefiles control chardev and then passing it
     through security_change_sid() to ask the security policy to for label (c).

 (*) When accessing the cache to look up a cache object (equivalent to NFS read
     inode), the CacheFiles module will make temporary substitutions for the
     following process security attributes:

     (1) current->fsuid and current->fsgid will both become 0.

     (2) current->security->create_sid will be set to label (a) so that
         vfs_mkdir() and vfs_create() will set the correct labels.

     (3) current->security->sid will be set to label (c) so that vfs_mkdir(),
         vfs_create() and lookup ops will check for the correct labels.

     After the access, the old label will be restored.

     Point (3) shouldn't cause a cross-thread race as it would appear that the
     security label can only be changed on single-threaded processes.  Attempts
     to do so on multi-threaded processes are rejected.

David