[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Xine.LNX.4.64.0803142039460.32184@us.intercode.com.au>
Date: Fri, 14 Mar 2008 21:17:12 +1100 (EST)
From: James Morris <jmorris@...ei.org>
To: "Serge E. Hallyn" <serue@...ibm.com>
cc: lkml <linux-kernel@...r.kernel.org>,
linux-security-module@...r.kernel.org,
Linux Containers <containers@...ts.osdl.org>,
Casey Schaufler <casey@...aufler-ca.com>,
Greg KH <greg@...ah.com>, Pavel Emelianov <xemul@...nvz.org>,
Stephen Smalley <sds@...ch.ncsc.mil>
Subject: Re: [PATCH] cgroups: implement device whitelist lsm (v3)
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@...ei.org>
--
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