Message-Id: <1187010071.26008.24.camel@moss-spartans.epoch.ncsc.mil>
Date:	Mon, 13 Aug 2007 09:01:11 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	casey@...aufler-ca.com
Cc:	David Howells <dhowells@...hat.com>, torvalds@...l.org,
	akpm@...l.org, steved@...hat.com, trond.myklebust@....uio.no,
	linux-fsdevel@...r.kernel.org, linux-cachefs@...hat.com,
	nfsv4@...ux-nfs.org, linux-kernel@...r.kernel.org,
	selinux@...ho.nsa.gov,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 00/16] Permit filesystem local caching [try #3]

On Sat, 2007-08-11 at 08:56 -0700, Casey Schaufler wrote:
> --- David Howells <dhowells@...hat.com> wrote:
> 
> > Casey Schaufler <casey@...aufler-ca.com> wrote:
> > 
> > > How would you expect an LSM that is not SELinux to interface with
> > > CacheFiles?
> > 
> > You have to understand that I didn't know that much about the LSM interface,
> > so I asked advice of the Red Hat security people, who, naturally, pointed me
> > at the SELinux mailing list.  I knew my stuff would have to work with SELinux
> > to be used with RH stuff.
> 
> Sigh. So it's not only SELinux specific, but RedHat specific as well.
> 
> > Furthermore, as you pointed out, there aren't any other LSM modules upstream
> > yet for me to work against.  I would like CacheFiles to work with all LSM
> > modules in general, but I don't know how to do that yet.
> 
> While neither is upstream you can certainly look at AppArmor and Smack,
> both of which have nefarious plans for getting upstream.
> 
> > I'm open to suggestion as to how to modify things to support any LSM.
> 
> It's been a long time since I dealt with file system cacheing, and
> that was under Unix, and I don't claim to have a working understanding
> of the internals of CacheFiles, but ...
> 
> > Btw, do you understand the problems that CacheFiles has to deal with?  If I
> > set this down clearly, this may help you or someone else suggest a better way
> > to do things.
> > 
> >   (1) Some random process tries to access a file on a network filesystem
> >       (NFS example).
> > 
> >   (2) NFS goes to the cache to attempt to read the data from there prior to
> >       going to the network.
> > 
> >   (3) The cache driver wants to access the files in the cache, but it's
> >       running in the security context of either the aforementioned random
> >       process, or one of FS-Cache's thread pool.
> 
> I think that this is the point you should attack. Control the security
> characteristics of the cache driver properly and you shouldn't need the
> complexity that you're asking to introduce.
>  
> >       This security context, however, doesn't necessarily give it the rights
> >       to access what's in the cache, so the driver has to be permitted to act
> >       as a context appropriate to accessing the cache, without changing the
> >       overall security context of the random process (which would impact
> >       things trying to act on that process - kill() for example).
> 
> Can you run the cache as an independent thread and send it messages
> rather than trying to do things in the context of the calling process?
> I know that that involves extra bookkeeppingg, but it's lots safer.
> 
> >   (4) Assuming the data is found in the cache, all well and good, but if it
> >       isn't, the cache driver will have to create some files in the cache.
> > 
> >       Now, if the cache driver just went ahead and created the files, they
> >       could end up with their own security contexts being derived from the
> >       random process's security context, thus potentially making it
> > impossible
> >       for other processes to access the cache.
> 
> Yes, and the SELinux semantics for what label to give a file don't
> help much, either. The problem with the "act_as" interfaces is that
> I wouldn't expect them to be any more reliable than the old access()
> system call, which never really gave you a helpful answer.
>  
> >       So the file-creation part of the security context must also be
> >       overridden temporarily, assuming that whatever LSM is in force has such
> >       a concept.
> 
> Ideally you want to be running in the right context to create the
> new file so that no one can use it and then label it "correctly"
> and make it available.
> 
> > Part of the problem is that the VFS does not pass around the security context
> > as which the VFS routines act, but rather gets them from the task_struct. 
> 
> That's by design. 
> 
> > For
> > the most part, this is entirely sufficient, but in the cache driver case,
> > it's
> > a problem.
> 
> The cache driver is a unique case with an unusual function. It's pretty
> obvious that the kernel architecture, the VFS architecture, LSM, SELinux,
> NFS and pretty much everyone else has given no thought whatever to the
> implications of their designs on file system cacheing. For all concerned,
> I'll say "sorry 'bout that".

Parts of it are unique, but some of the same issues crop up in nfs - we
will need a way there as well for nfsd to assume the client process'
label for permission checking and new file labeling purposes, and the
act_as hook is not fundamentally different than what nfsd does today
with the fsuid/fsguid, just applied to the security label.

-- 
Stephen Smalley
National Security Agency

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

Powered by blists - more mailing lists