Messages in this thread | | | Date | Fri, 14 Mar 2008 17:05:14 +0300 | From | Pavel Emelyanov <> | Subject | Re: [RFC] cgroups: implement device whitelist lsm (v2) |
| |
Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> Serge E. Hallyn wrote: >>> Quoting James Morris (jmorris@namei.org): >>>> On Thu, 13 Mar 2008, Serge E. Hallyn wrote: >>>> >>>>> Quoting James Morris (jmorris@namei.org): >>>>>> On Thu, 13 Mar 2008, Serge E. Hallyn wrote: >>>>>> >>>>>>> True, but while this change simplifies the code a bit, the semantics >>>>>>> seem more muddled - devcg will be enforcing when CONFIG_CGROUP_DEV=y >>>>>>> and: >>>>>>> >>>>>>> SECURITY=n or >>>>>>> rootplug is enabled >>>>>>> capabilities is enabled >>>>>>> smack is enabled >>>>>>> selinux+capabilities is enabled >>>>>> Well, this is how real systems are going to be deployed. >>>>> Sorry, do you mean with capabilities? >>>> Yes. >>>> >>>> All Fedora, RHEL, CentOS etc. ship with SELinux+capabilities. I can't >>>> imagine not enabling them on other kernels. >>>> >>>>>> It becomes confusing, IMHO, if you have to change which secondary LSM you >>>>>> stack with SELinux to enable a cgroup feature. >>>>> So you're saying selinux without capabilities should still be able to >>>>> use dev_cgroup? (Just making sure I understand right) >>>> Nope, SELinux always stacks with capabilities, so havng the cgroup hooks >>>> in capabilities makes sense (rather than having us change the secondary >>>> stacking LSM just to enable a feature). >>> Oh, ok. >>> >>> Will let the patch stand until Pavel and Greg comment then. >> Well, I saw your previous patch, that was implemented as just another >> LSM module and I liked it except for the LSM dependency. > > James and Stephen agree with your LSM qualms. I suppose we could add
Thanks!
> cgroups next to the lsm hooks. I suspect Paul Menage would complain > about that (Paul?), and I do think it's silly as they are security > questions, not group tracking questions, but if it's what people want > I can send out a new patch next week.
The way I see this is: cgroups provide a common way to group tasks and an API for general configuration - that's the controller "face", and it's up to the controller to decide where he turns his "back", IOW where the hooks are placed. For the memory controller - they are injected directly into the mm code. For this controller, I think it would be OK to use LSM or about-LSM hooks.
>> Since this version can happily work w/o LSM, I like it too :) > > In an earlier version I asked whether you had any experience with usual > # rules per container. Do you have an idea? Right now the whitelist is > a straight list we search through linearly. If # rules is generally > tiny then I'm inclined to keep it that way...
The # of rules usually has a linear dependency on the number of containers (each of then has to have an access to /dev/null,zero,random at least), so having 100 containers we will have to scan through a 300-entries list. I'd vote for a hash table or a radix/binary/rb tree for that. Or any other way for non-linear search you can provide :)
> thanks, > -serge >
| |