Messages in this thread |  | | | Subject | Re: Security issues with local filesystem caching | | From | Trond Myklebust <> | | Date | Thu, 02 Nov 2006 14:49:27 -0500 |
| |
On Thu, 2006-11-02 at 17:16 +0000, David Howells wrote: > Stephen Smalley <sds@tycho.nsa.gov> wrote: > > Unless there is some benefit to setting a ->fssid and checking against > > it (e.g. safeguarding the module against unintentional internal access), > > I think the task flag approach is preferable. > > Well, I think the use of ->fssid is simpler and faster from an implementation > standpoint (see the attached patch), and it can always be used for such as the > in-kernel nfsd later. > > The way I've done it in this patch is to have ->fssid shadow ->sid as long as > they're the same. But ->fssid can be set to something else and then later > reset, at which point it becomes the same as ->sid again. A hook is provided > to perform both of these operations: > > security_set_fssid(overriding_SID); //set > ... > security_set_fssid(SECSID_NULL); //reset > > The rest of the patch is that more or less anywhere ->sid is used to represent > a process as an actor, this is replaced with ->fssid. This part requires no > conditional jumps. It becomes a bit tricky around execve() time, but I think > it's reasonable to ignore that as execve() is unlikely to happen in an > overridden context; or maybe the execve() related ops should be failed if > ->sid != ->fssid. > > Do you think this is reasonable? Or do you definitely want me to use the > suppression flag approach instead?
Just why are you doing all this? Why do we need a back-end that requires all this extra client-side security infrastructure in order to work?
IOW: What is wrong with the existing CacheFS?
Trond
- 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/
|  |