From: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
linux-security-module@vger.kernel.org,
Linux Containers <containers@lists.osdl.org>,
Casey Schaufler <casey@schaufler-ca.com>,
Greg KH <greg@kroah.com>, Pavel Emelianov <xemul@openvz.org>,
Stephen Smalley <sds@epoch.ncsc.mil>
Subject: Re: [PATCH] cgroups: implement device whitelist lsm (v3)
Date: Fri, 14 Mar 2008 21:17:12 +1100 (EST) [thread overview]
Message-ID: <Xine.LNX.4.64.0803142039460.32184@us.intercode.com.au> (raw)
In-Reply-To: <20080313144142.GB11265@sergelap.austin.ibm.com>
On Thu, 13 Mar 2008, Serge E. Hallyn wrote:
> Implement a cgroup using the LSM interface to enforce open and mknod
> on device files.
Actually, I'm not sure that the LSM approach in general is best here.
The LSM model is that standard DAC logic lives in the core kernel, and
that extended security logic (e.g. MAC) is called after DAC via hooks.
cgroups has introduced new security logic of its own, which is arguably
"standard DAC" when cgroups is enabled.
I can understand Greg not wanting this security logic in the core kernel,
but it is specific to cgroups (which itself is security model agnostic)
and does not stand alone as a distinct security framework.
The fact that all existing LSMs need to invoke exactly the same code is an
indicator that it doesn't belong in LSM.
Moving this logic into LSM means that instead of the cgroups security
logic being called from one place in the main kernel (where cgroups
lives), it must be called identically from each LSM (none of which are
even aware of cgroups), which I think is pretty obviously the wrong
solution.
This is baggage which comes with cgroups -- please don't push it into LSM
to try and hide that.
- James
--
James Morris
<jmorris@namei.org>
next prev parent reply other threads:[~2008-03-14 10:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-13 14:41 [PATCH] cgroups: implement device whitelist lsm (v3) Serge E. Hallyn
2008-03-14 10:17 ` James Morris [this message]
2008-03-14 13:27 ` Stephen Smalley
2008-03-14 14:32 ` Serge E. Hallyn
2008-03-14 17:41 ` Stephen Smalley
2008-03-14 22:44 ` Casey Schaufler
2008-03-17 13:26 ` Stephen Smalley
2008-03-18 6:48 ` Greg KH
2008-03-17 14:08 ` Serge E. Hallyn
2008-03-17 16:16 ` Casey Schaufler
2008-03-17 16:48 ` Stephen Smalley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Xine.LNX.4.64.0803142039460.32184@us.intercode.com.au \
--to=jmorris@namei.org \
--cc=casey@schaufler-ca.com \
--cc=containers@lists.osdl.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sds@epoch.ncsc.mil \
--cc=serue@us.ibm.com \
--cc=xemul@openvz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox