Re: Security issues with local filesystem caching

[David Howells <dhowells@redhat.com>]

Stephen Smalley <sds@tycho.nsa.gov> wrote:

> We might want more information passed into the hook, like the cache
> directory itself,

I can do that.  I have the cache directory path and the cache tag name both
available as strings.

> 	int security_cache_set_context(struct vfsmount *mnt, struct dentry *dentry, u32 secid)
> 	{

Where are you envisioning this going?  In SELinux, in the LSM core or in
cachefiles?  I was also wondering if I could generalise it to handle all cache
types, but the permissions checks are probably going to be quite different for
each type.  For instance, CacheFiles uses files on a mounted fs, whilst CacheFS
uses a block device.

> We would either need to introduce new permission definitions to SELinux to
> distinguish this operation, or we would need to map it to something similar,
> e.g. apply the same checks that we would perform if the cache daemon was
> directly trying to set its fscreate value to this context and create files in
> that context.

Mapping it to something similar sounds reasonable, though I'd quite like
something general, so that I can check for any type of cache coming up.

Also, with your multiple cache example, how would I bring each cachefilesd
daemon up in a different context so that it could handle a different cache with
a different context?

> > That sounds doable.  I presume I should attend to fsuid/fsgid myself, much
> > as I'm doing now?
> 
> Yes, I think so, although you may want to make those values configurable
> too (although it isn't clear that a cache daemon can be run as non-root
> at present).

Actually, that's not something I had considered, but there's no particular
reason that files in the cache have to be owned by root specifically; nor is
there a reason why cachefilesd needs to run as root.  The main thing is that
the files are owned by whatever user the daemon runs as.  It'd mean creating
another special user for it, but we do that all the time...

> I think we likely also want to refer to the above secid as fscreateid or
> similar instead of just fsecid for clarity, because it isn't quite the
> same thing as a fsuid/fsgid; it is _only_ used for labeling of new
> files, not as the label of the process for permission checking purposes.
> So it would be security_getfscreateid() and security_setfscreateid().
> Process labels and file labels are distinct.

Gotcha.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/