linux-kernel - Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

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: <1200424508.9669.63.camel@moss-spartans.epoch.ncsc.mil>
Date:	Tue, 15 Jan 2008 14:15:08 -0500
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	casey@...aufler-ca.com
Cc:	David Howells <dhowells@...hat.com>,
	Daniel J Walsh <dwalsh@...hat.com>,
	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM
	settings for task actions [try #2]


On Tue, 2008-01-15 at 10:10 -0800, Casey Schaufler wrote:
> --- David Howells <dhowells@...hat.com> wrote:
> 
> > Stephen Smalley <sds@...ho.nsa.gov> wrote:
> > 
> > > >  (3) Check that the kernel may create files as a particular secid (this
> > > >      could be specified indirectly by specifying an inode, which would
> > > >      hide the secid inside the LSM).
> > > 
> > > I don't think this check is on the kernel per se but rather the ability
> > > of the daemon to nominate a secid for use on files created later by the
> > > kernel module.
> > 
> > Hmmm...  At the moment the cachefiles module works out for itself what the
> > file label should be by looking at the root directory it was given and
> > assuming the label on that is what it's going to be using.  Are you
> > suggesting
> > this should be specified directly instead by the daemon?
> 
> Oh my. While there will be cases where the label of the file
> will match the label of the containing directory, and in fact
> for most label based LSMs that will usually be the case, you
> certainly can't count on it. The only place that you can find
> the correct label for a file with any confidence in from the
> xattr (assuming the LSM uses xattrs) on the file itself. I can
> imaging an LSM for which it would make sense to derive the
> label from the root directory, but I know Smack isn't one of
> them, and I don't think that SELinux is either, although I
> would defer a definitive answer on that to Stephen.

The cache files are created by the cachefiles kernel module, not by the
userspace daemon, and the userspace daemon doesn't need to directly
read/write them at all (but I think it does need to be able to unlink
them?).  The userspace daemon merely identifies the directory where the
cache should live as part of configuring the cache when enabling it.

Hence, it is fine to use a fixed label for the cache files (systemhigh
in a MLS world), and to let the directory's label serve as the basis for
it.  Only the cachefiles kernel module directly reads and writes the
files.
 
-- 
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/