Messages in this thread | | | Date | Fri, 14 Mar 2008 09:37:52 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC] cgroups: implement device whitelist lsm (v2) |
| |
Quoting Pavel Emelyanov (xemul@openvz.org): > 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.
Oh no, the rules are stored per-container, so it sounds like you're saying 3 entries per container?
> 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 :)
I'm fine with that, but not for 3 rules :)
-serge
| |