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
| ||
|
Date: Tue, 11 Dec 2007 11:26:29 -0800 (PST) From: Casey Schaufler <casey@...aufler-ca.com> To: Stephen Smalley <sds@...ho.nsa.gov>, casey@...aufler-ca.com Cc: David Howells <dhowells@...hat.com>, Karl MacMillan <kmacmill@...hat.com>, viro@....linux.org.uk, hch@...radead.org, Trond.Myklebust@...app.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] --- Stephen Smalley <sds@...ho.nsa.gov> wrote: > On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote: > > --- Stephen Smalley <sds@...ho.nsa.gov> wrote: > > > > > On Mon, 2007-12-10 at 21:08 +0000, David Howells wrote: > > > > Stephen Smalley <sds@...ho.nsa.gov> wrote: > > > > > > > > > Otherwise, only other issue I have with this interface is it won't > > > > > generalize to dealing with nfsd, where we want to set the acting > context > > > > > to a context we obtain from or determine based upon the client. > > > > > > > > Are you speaking of security_kernel_act_as() and > security_create_files_as() > > > > specifically? Or the task_struct::act_as override pointer in general? > > > > > > security_kernel_act_as() > > > > > > > I don't really know how nfsd wants to obtain and set its LSM context, > so > > > it's > > > > a bit difficult for me to make something that works for nfsd as well as > > > > cachefiles. > > > > > > It would get a context from the client or from a local configuration > > > that would map security-unaware clients to a default context, and then > > > want to assume that context for the particular operation. No transition > > > involved. > > > > I would expect that the operation would be more sophisticated > > than that. You certainly aren't going to use what comes from > > the other side without any processing, and I expect you'll have > > some sort of operation on anything you pull from a config file > > before you actually apply it. > > Yes, that's true - the contexts would be subjected to a permission > check. But that's separable from the act of setting it as the task's > acting security state (and needs to be separated, as the precise check > will vary depending on the situation - cachefiles is going to apply a > different sort of check than nfsd). > > > > > > Why can't cachefilesd just push a context into the kernel and pass > that > > > > > into the hook as the acting context, > > > > > > > > How does cachefilesd come up with such a context? Grab it from > > > > /etc/cachefilesd.conf? > > > > > > >From a config file whose pathname would be provided by libselinux (ala > > > the way in which dbusd imports contexts), or directly as a context > > > returned by a libselinux function. Has to be done that way so that it > > > can be set differently for different policy types (strict, targeted, > > > mls). > > > > Unless you've got an LSM other than SELinux, of course. If > > cachefilesd is going to be responsible for maintaining this > > magic context there needs to be an LSM interface for it, not > > just an SELinux interface. > > LSM is an in-kernel interface. Here we are talking about a userspace > interface for obtaining the right security label to use. There is no > equivalent to LSM in userspace as of yet. Feel free to invent one, but > don't ask the rest of us to do it or wait for it to materialize. I am much more concerned with the interfaces used to pass the information into the kernel. I would expect that to be LSM independent, not a call into libselinux that resolves into a selinuxfs operation, or it's netlink equivilant. It would be unfortunate if the userland/kernel interface became an obstacle to cachefiles being adopted. > ... 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/
Powered by blists - more mailing lists