David Howells <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
