OpenVZ Forum - RDF feed
type: channel
items: [PATCH] cgroups: implement device whitelist lsm (v3)
items: Re: [PATCH] cgroups: implement device whitelist lsm (v3)

[PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: Implement a cgroup using the LSM interface to enforce open and mknod on device files. This implements a simple device access whitelist. A whitelist entry has 4 fields. 'type' is a (all), c (char), or b (block). 'all' means it applies to all types, all major numbers, and all minor numbers. Major and minor are obvious. Access is a composition of r (read), w (write), and m (mknod). The root devcgroup starts with rwm to 'all'. A child devcg gets a copy of the parent. Admins can then add and remove devices to the whitelist. Once CAP_HOST_ADMIN is introduced it will be needed to add entries as well or remove entries from another cgroup, though just CAP_SYS_ADMIN will suffice to remove entries for your own group. An entry is added by doing "echo <type> <maj> <min> <access>" > devcg.allow, for instance: echo b 7 0 mrw > /cgroups/1/devcg.allow An entry is removed by doing likewise into devcg.deny. Since this is a pure whitelist, not acls, you can only remove entries which exist in the whitelist. You must explicitly echo a 0 0 mrw > /cgroups/1/devcg.deny to remove the "allow all" entry which is automatically inherited from the root cgroup. While composing this with the ns_cgroup may seem logical, it is not the right thing to do, because updates to /cg/cg1/devcg.deny are not reflected in /cg/cg1/cg2/devcg.allow. A task may only be moved to another devcgroup if it is moving to a direct descendent of its current devcgroup. CAP_NS_OVERRIDE is defined as the capability needed to cross namespaces. A task needs both CAP_NS_OVERRIDE and CAP_SYS_ADMIN to create a new devcgroup, update a devcgroup's access, or move a task to a new devcgroup. CONFIG_COMMONCAP is defined whenever security/commoncap.c should be compiled, so that the decision of whether to show the option for FILE_CAPABILITIES can be a bit cleaner. Changelog: Mar 13 2008: move the dev_cgroup support into capability hooks instead of having it as a separate security module. Support root_plug with devcg. Note that due to this…
creator: serue
date: 2008-03-13T14:41:42-00:00

Re: [PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: 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> _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: James Morris
date: 2008-03-14T10:17:12-00:00

Re: [PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: On Fri, 2008-03-14 at 21:17 +1100, James Morris wrote: > 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. I agree with the above, and would further note that I would expect the SELinux solution to the problem would be done not by stacking with or calling this device whitelist lsm but instead by introducing the ability to bind security labels to devices within the kernel (independent of the particular device node(s) in the filesystem used to access that device) and applying permission checks on those device labels when processes attempt to create or access those devices (again independent of the particular device node used to access them). That keeps the policy integrated and analyzable and avoids an external dependency. -- Stephen Smalley National Security Agency _______________________________________________ Containers ma…
creator: Stephen Smalley
date: 2008-03-14T13:27:28-00:00

Re: [PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: Quoting Stephen Smalley (sds@epoch.ncsc.mil): > > On Fri, 2008-03-14 at 21:17 +1100, James Morris wrote: > > 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. I completely disagree. We have two separate frameworks in the kernel, one to enforce generic additional security stuff, and one to track tasks. When I need a feature which tracks tasks to do some security tasks, it seems obvious that I would use both, just like to enforce a certain type of MAC I end up using both netfilter and LSM through selinux. > > The fact that all existing LSMs need to invoke exactly the same code is an > > indicator that it doesn't belong in LSM. No, that's like saying capabilities don't belong in LSM because all LSMS need to invoke it the same way. What it is an indicator of is that there are (not-quite-)orthogonal pieces of security which users might want to use together. As I told stephen I hope to provide the enhanced selinux support for devices, and at that point perhaps you won't want to support SELINUX+CGROUPS_DEV anymore. Now that's just my opinion and it doesn't count for much. I'll do whatever everyone can agree on, but will wait for Paul's opinion about adding cgroup hooks next to the two security hooks. > > Moving this logic into LSM means that instead of the cgroups security > > logic being called from one place in the…
creator: serue
date: 2008-03-14T14:32:16-00:00

Re: [PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: On Fri, 2008-03-14 at 09:32 -0500, Serge E. Hallyn wrote: > Quoting Stephen Smalley (sds@epoch.ncsc.mil): > > > > On Fri, 2008-03-14 at 21:17 +1100, James Morris wrote: > > > 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. > > I completely disagree. We have two separate frameworks in the kernel, > one to enforce generic additional security stuff, and one to track > tasks. When I need a feature which tracks tasks to do some security > tasks, it seems obvious that I would use both, just like to enforce a > certain type of MAC I end up using both netfilter and LSM through > selinux. Depends on whether you think LSM hooks are like netfilter hooks (i.e. fine for each module to just implement a few here and there, then combine resulting modules), or whether they are about implementing complete security models (ala SELinux or Smack). As they currently exist, they aren't very well suited to the former - they impose a cost on all hooked operations in order to hook any at all, as has been a concern for your device controller. > > > The fact that all existing LSMs need to invoke exactly the same code is an > > > indicator that it doesn't belong in LSM. > > No, that's like saying capabilities don't belong in LSM because all LSMS > need to invoke it the same way. What it is an indicator of is …
creator: Stephen Smalley
date: 2008-03-14T17:41:56-00:00

Re: [PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: --- Stephen Smalley <sds@epoch.ncsc.mil> wrote: > > ... > > I completely disagree. We have two separate frameworks in the kernel, > > one to enforce generic additional security stuff, and one to track > > tasks. When I need a feature which tracks tasks to do some security > > tasks, it seems obvious that I would use both, just like to enforce a > > certain type of MAC I end up using both netfilter and LSM through > > selinux. > > Depends on whether you think LSM hooks are like netfilter hooks (i.e. > fine for each module to just implement a few here and there, then > combine resulting modules), or whether they are about implementing > complete security models (ala SELinux or Smack). As they currently > exist, they aren't very well suited to the former - they impose a cost > on all hooked operations in order to hook any at all, as has been a > concern for your device controller. I don't intend that Smack be thought of as a complete security model. Smack implements Mandatory Access Control, but leaves the privilege mechanism (root and/or capabilities) to the whims of others. Similarly Smack does not do DAC (unlike SELinux with MCS) although "owned rules" has been proposed as an additional feature. I certainly wouldn't want every new facility that comes in to require multiple versions that depend on the other LSMs involved. It's true that today's LSM is optimized for the only LSM that existed a year ago, and that was a monolythic security model. > > > > The fact that all existing LSMs need to invoke exactly the same code is > an > > > > indicator that it doesn't belong in LSM. > > > > No, that's like saying capabilities don't belong in LSM because all LSMS > > need to invoke it the same way. What it is an indicator of is that > > there are (not-quite-)orthogonal pieces of security which users might > > want to use together. > > Likely not a popular view, but capabilities don't belong in LSM. I share this view, which add credibility to the claim that it's not popular. (…
creator: Casey Schaufler
date: 2008-03-14T22:44:26-00:00

Re: [PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: On Fri, 2008-03-14 at 15:44 -0700, Casey Schaufler wrote: > --- Stephen Smalley <sds@epoch.ncsc.mil> wrote: > > > > > ... > > > I completely disagree. We have two separate frameworks in the kernel, > > > one to enforce generic additional security stuff, and one to track > > > tasks. When I need a feature which tracks tasks to do some security > > > tasks, it seems obvious that I would use both, just like to enforce a > > > certain type of MAC I end up using both netfilter and LSM through > > > selinux. > > > > Depends on whether you think LSM hooks are like netfilter hooks (i.e. > > fine for each module to just implement a few here and there, then > > combine resulting modules), or whether they are about implementing > > complete security models (ala SELinux or Smack). As they currently > > exist, they aren't very well suited to the former - they impose a cost > > on all hooked operations in order to hook any at all, as has been a > > concern for your device controller. > > I don't intend that Smack be thought of as a complete security model. > Smack implements Mandatory Access Control, but leaves the privilege > mechanism (root and/or capabilities) to the whims of others. Similarly > Smack does not do DAC (unlike SELinux with MCS) although "owned rules" > has been proposed as an additional feature. I certainly wouldn't > want every new facility that comes in to require multiple versions > that depend on the other LSMs involved. It's true that today's LSM is > optimized for the only LSM that existed a year ago, and that was a > monolythic security model. By complete security model, I don't mean it has to be MAC+DAC +privileges. Just that it does in fact implement a well formed security model, not just an ad hoc set of stupid security tricks. Smack and SELinux are examples of the former. > > > > > The fact that all existing LSMs need to invoke exactly the same code is > > an > > > > > indicator that it doesn't belong in LSM. > > > > > > No, that's like saying capabil…
creator: Stephen Smalley
date: 2008-03-17T13:26:39-00:00

Re: [PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: Quoting Casey Schaufler (casey@schaufler-ca.com): > > --- Stephen Smalley <sds@epoch.ncsc.mil> wrote: > > > > > ... > > > I completely disagree. We have two separate frameworks in the kernel, > > > one to enforce generic additional security stuff, and one to track > > > tasks. When I need a feature which tracks tasks to do some security > > > tasks, it seems obvious that I would use both, just like to enforce a > > > certain type of MAC I end up using both netfilter and LSM through > > > selinux. > > > > Depends on whether you think LSM hooks are like netfilter hooks (i.e. > > fine for each module to just implement a few here and there, then > > combine resulting modules), or whether they are about implementing > > complete security models (ala SELinux or Smack). As they currently > > exist, they aren't very well suited to the former - they impose a cost > > on all hooked operations in order to hook any at all, as has been a > > concern for your device controller. > > I don't intend that Smack be thought of as a complete security model. > Smack implements Mandatory Access Control, but leaves the privilege > mechanism (root and/or capabilities) to the whims of others. Similarly > Smack does not do DAC (unlike SELinux with MCS) although "owned rules" > has been proposed as an additional feature. I certainly wouldn't > want every new facility that comes in to require multiple versions > that depend on the other LSMs involved. It's true that today's LSM is > optimized for the only LSM that existed a year ago, and that was a > monolythic security model. > > > > > > The fact that all existing LSMs need to invoke exactly the same code is > > an > > > > > indicator that it doesn't belong in LSM. > > > > > > No, that's like saying capabilities don't belong in LSM because all LSMS > > > need to invoke it the same way. What it is an indicator of is that > > > there are (not-quite-)orthogonal pieces of security which users might > > > want to use together. > > > > Likely not a …
creator: serue
date: 2008-03-17T14:08:53-00:00

Re: [PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: --- "Serge E. Hallyn" <serue@us.ibm.com> wrote: > Quoting Casey Schaufler (casey@schaufler-ca.com): > ... > > In particular, capabilities are not an access control mechanism, > > they are a privilege mechanism. A lot of discussion about LSM has > > centered around the appropriate charactoristics of an LSM, and > > these discussions always assume that the LSM in question is > > exactly an access control mechanism. If we split the LSM into > > a LACM for access control and an LPM for privilege management > > maybe we can eliminate the most contentious issues. > > > > Does anyone know why that would be stoopid before I whack out > > patches? > > No I'd like to see those patches. It would ideally allow LSM to become > *purely* restrictive and LPM to be purely empowering, presumably making > the resulting hook sets easier to review and maintain. The LPM wouldn't > (I assume) gain any *new* hook points so we wouldn't be adding any new > places for hooks to be overriden by a rootkit. I don't expect to put in any additional hooks points, although it's safe to bet that someone will want to pretty quickly. What I see as the big concern is our old friend the granularity question. I can pretty well predict that we'll have quite a bruhaha over whether each hook point should have it's own hook or if they should be shared based on the privilege supported. For example, in namei.c the function generic_permission() currently calls capable(CAP_DAC_OVERRIDE). The privilege supported approach would be to create a hook that gets used in many places that is a drop-in replacement for that, if (capable(CAP_DAC_OVERRIDE)) becomes if (lpm_dac_override()) The alternative is to go the same route as the LSM, where it becomes if (lpm_generic_permission_may_exec()) The former scheme is much easier to implement. It also would mean that if would wanted to implement a finer granularity on DAC overrides (e.g. CAP_DAC_READ, CAP_DAC_WRITE, CAP_DAC_EXECUTE) you would have to introduce new hooks. That wou…
creator: Casey Schaufler
date: 2008-03-17T16:16:42-00:00

Re: [PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: On Mon, 2008-03-17 at 09:16 -0700, Casey Schaufler wrote: > --- "Serge E. Hallyn" <serue@us.ibm.com> wrote: > > > Quoting Casey Schaufler (casey@schaufler-ca.com): > > ... > > > In particular, capabilities are not an access control mechanism, > > > they are a privilege mechanism. A lot of discussion about LSM has > > > centered around the appropriate charactoristics of an LSM, and > > > these discussions always assume that the LSM in question is > > > exactly an access control mechanism. If we split the LSM into > > > a LACM for access control and an LPM for privilege management > > > maybe we can eliminate the most contentious issues. > > > > > > Does anyone know why that would be stoopid before I whack out > > > patches? > > > > No I'd like to see those patches. It would ideally allow LSM to become > > *purely* restrictive and LPM to be purely empowering, presumably making > > the resulting hook sets easier to review and maintain. The LPM wouldn't > > (I assume) gain any *new* hook points so we wouldn't be adding any new > > places for hooks to be overriden by a rootkit. > > I don't expect to put in any additional hooks points, although > it's safe to bet that someone will want to pretty quickly. What > I see as the big concern is our old friend the granularity question. > I can pretty well predict that we'll have quite a bruhaha over > whether each hook point should have it's own hook or if they should > be shared based on the privilege supported. For example, in namei.c > the function generic_permission() currently calls > capable(CAP_DAC_OVERRIDE). The privilege supported approach would > be to create a hook that gets used in many places that is a drop-in > replacement for that, > > if (capable(CAP_DAC_OVERRIDE)) > becomes > if (lpm_dac_override()) nit: I'd use priv_ rather than lpm_, just as we use security_ rather than lsm_. Do you plan to pass other arguments to the privilege hook call, like the object? If not, then there is no point in changing the capable …
creator: Stephen Smalley
date: 2008-03-17T16:48:10-00:00

Re: [PATCH] cgroups: implement device whitelist lsm (v3)
type: item
description: On Mon, Mar 17, 2008 at 09:26:39AM -0400, Stephen Smalley wrote: > > > The original promise was that LSM would allow kernels to be built that > > > shed capabilities altogether, > > > > I don't remember that, but it's been a long time so it could be true. > > "One of the explicit requirements to get LSM into the kernel was to have > the ability to make capabilities be a module. This allows the embedded > people to completely remove capabilities, as they really want this. I > don't think we can ignore this, no matter how much of a pain in the butt > it is :)" - Greg KH > > Quoted from: > http://marc.info/?l=linux-security-module&m=99236500727804&w=2 > > Ironically, since that time, capabilities have doubled in size and still > can't be removed from the core kernel since LSM didn't push the state > into the security blobs. Maybe we need to seriously revisit this and perhaps rip capabilities back out and put it always into the kernel if it's always a requirement. Comments made 7 years ago might be totally wrong when we have now learned how this all has worked out... thanks, greg k-h _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Greg KH
date: 2008-03-18T06:48:42-00:00