linux-kernel - Re: [RFC] cgroups: implement device whitelist lsm (v2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080314143752.GE9741@sergelap.austin.ibm.com>
Date:	Fri, 14 Mar 2008 09:37:52 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Pavel Emelyanov <xemul@...nvz.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	James Morris <jmorris@...ei.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org, Greg KH <greg@...ah.com>,
	Stephen Smalley <sds@...ch.ncsc.mil>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [RFC] cgroups: implement device whitelist lsm (v2)

Quoting Pavel Emelyanov (xemul@...nvz.org):
> Serge E. Hallyn wrote:
> > Quoting Pavel Emelyanov (xemul@...nvz.org):
> >> Serge E. Hallyn wrote:
> >>> Quoting James Morris (jmorris@...ei.org):
> >>>> On Thu, 13 Mar 2008, Serge E. Hallyn wrote:
> >>>>
> >>>>> Quoting James Morris (jmorris@...ei.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
--
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/