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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
