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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <462850.65153.qm@web36605.mail.mud.yahoo.com>
Date:	Mon, 13 Aug 2007 14:44:40 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	David Howells <dhowells@...hat.com>, casey@...aufler-ca.com
Cc:	dhowells@...hat.com, Stephen Smalley <sds@...ho.nsa.gov>,
	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]


--- David Howells <dhowells@...hat.com> wrote:

> Casey Schaufler <casey@...aufler-ca.com> 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.


Casey Schaufler
casey@...aufler-ca.com
-
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/