Re: [PATCH 00/16] Permit filesystem local caching [try #3]

[Stephen Smalley]

On Mon, 2007-08-13 at 14:44 -0700, Casey Schaufler wrote:
> --- David Howells <dhowells@xxxxxxxxxx> wrote:
> 
> > Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> > 
> > > The specification of your push interface that the push operation
> > > not affect how others access the process is OK for SELinux, but
> > > not for any other MAC scheme that I've dealt with, and I think
> > > that's most of them. Nuts. Smack, for example, uses exactly one
> > > label on the process for all purposes.
> > 
> > It's a fairly important concept.  The victimisation security context on a
> > process must not change, even if the kernel overrides the security context
> > that that process acts as so that it can transparently do work on its behalf.
> > 
> > IMO, the right way to do this is to pass the security context directly to
> > vfs_mkdir() and co.
> > 
> > > Are you concerned about accesses other than signals? Signals
> > > could be staitforward to deal with in a pushed situation, but
> > > I'd hesitate to say that the solution would generalize without
> > > additional thought.
> > 
> > There's also /proc and ptrace() for example.  ps -z must not show the
> > overridden state.
> > 
> > > > > >   (5) int security_xfrm_to_kernel_context(void *from, void **_to);
> > > > > 
> > > > > Woof. What are you transforming from? 
> > > > 
> > > > In CacheFiles case, the cachefilesd daemon's security label into the
> > label
> > > > the cache driver acts as on behalf of other processes.
> > > 
> > > I'm not sure I understand what this is doing.
> > 
> > CacheFiles consists of two parts: the kernel module which creates things in
> > the cache and does accesses into the cache on behalf of processes that access
> > cached filesystems, and the userspace daemon that builds cull tables and
> > deletes things.
> > 
> > The reason there are two security labels is that the daemon's label gives it
> > just enough rights to be able to do its job.  More or less all it can do is
> > lookup, opendir, readdir, stat, rmdir, unlink and open the chardev for
> > talking
> > to the kernel module.  This means that the daemon can't, for example, be made
> > to read or modify cache storage objects.
> > 
> > Thus means, however, that the daemon's label isn't sufficient for the kernel
> > module to do its job.  But since there's no way for the kernel module to
> > directly get a label (and indeed it doesn't know the label it needs), a
> > transformation has to be applied that turns the process label used by the
> > daemon into a process label that the kernel, and only the kernel, can use.
> > 
> > The kernel's label gives it, amongst other things, the additional rights to
> > do
> > mkdir, creat, open, read, write, setxattr, getxattr, rename - things the
> > daemon isn't allowed to do.
> 
> With Smack you can leave the label alone, raise CAP_MAC_OVERRIDE,
> do your business of setting the label correctly, and then drop
> the capability. No new hooks required.

Except that CAP_MAC_OVERRIDE doesn't exist upstream, and if it did, it
would represent Smack-specific logic in the core kernel (when you're
complaining about SELinux-specific logic there).  So even that would
have to be encapsulated within a hook.

-- 
Stephen Smalley
National Security Agency

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