On Sat, 2007-08-11 at 08:56 -0700, Casey Schaufler wrote: > --- David Howells <dhowells@xxxxxxxxxx> wrote: > > > Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
