[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080401123218.GE12129@elf.ucw.cz>
Date: Tue, 1 Apr 2008 14:32:18 +0200
From: Pavel Machek <pavel@....cz>
To: "Serge E. Hallyn" <serue@...ibm.com>
Cc: lkml <linux-kernel@...r.kernel.org>, daniel@...ac.com,
lizf@...fujitsu.com, Pavel Emelyanov <xemul@...nvz.org>,
Greg KH <greg@...ah.com>, Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH 1/1] cgroups: implement device whitelist (v6)
On Mon 2008-03-31 09:00:53, Serge E. Hallyn wrote:
> Quoting Pavel Machek (pavel@....cz):
> > On Wed 2008-03-26 13:05:43, Serge E. Hallyn wrote:
> > > (This is identical to the version I sent on Mar 19 in response to
> > > the comments by Daniel Hokka Zakrisson, which are the last
> > > comments I've gotten.)
> > >
> > > Implement a cgroup to track and enforce open and mknod restrictions on device
> > > files. A device cgroup associates a device access whitelist with each
> > > cgroup. A whitelist entry has 4 fields. 'type' is a (all), c (char), or
> > > b (block). 'all' means it applies to all types and all major and minor
> > > numbers. Major and minor are either an integer or * for all.
> > > Access is a composition of r (read), w (write), and m (mknod).
> > >
> > > The root device cgroup starts with rwm to 'all'. A child devcg gets
> > > a copy of the parent. Admins can then remove devices from the
> > > whitelist or add new entries. A child cgroup can never receive a
> > > device access which is denied its parent. However when a device
> > > access is removed from a parent it will not also be removed from the
> > > child(ren).
> > >
> > > An entry is added using devices.allow, and removed using
> > > devices.deny. For instance
> > >
> > > echo 'c 1:3 mr' > /cgroups/1/devices.allow
> > >
> > > allows cgroup 1 to read and mknod the device usually known as
> > > /dev/null. Doing
> > >
> > > echo a > /cgroups/1/devices.deny
> >
> > Can't you use selinux or something?
>
> No. At the moment SELinux can't authorize based on type/major:minor. I
> would like to add that support later on, but even when I do, folks such
> as the openvz folks do not want to rely on any security modules.
Yep, it looks like openvz folks do not want to rely on any security
modules, do not want to fix their userland, and do not have a taste
when implementing new features.
IMO that means openvz folks should be kept off mainline.
Implementing SELinux extension that can authorize based on
type/major:minor seems like a way to go to me....
> > > --- a/include/linux/cgroup_subsys.h
> > > +++ b/include/linux/cgroup_subsys.h
> > > @@ -42,3 +42,9 @@ SUBSYS(mem_cgroup)
> > > #endif
> > >
> > > /* */
> > > +
> > > +#ifdef CONFIG_CGROUP_DEVICE
> > > +SUBSYS(devices)
> > > +#endif
> > > +
> > > +/* */
> >
> > I don't know what this is, but it does not look like C...
>
> Huh?
Empty comments as separators? What does magical SUBSYS macro do?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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