(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

will remove the default 'a *:* mrw' entry.

CAP_SYS_ADMIN is needed to change permissions or move another task
to a new cgroup.  A cgroup may not be granted more permissions than
the cgroup's parent has.  Any task can move itself between cgroups.
This won't be sufficient, but we can decide the best way to
adequately restrict movement later.

Changelog:
	Mar 19 2008: Address dangerous bugs pointed out by
		Daniel Hokka Zakrisson.
	Mar 18 2008: Address comments by Li Zefan.
	Mar 17 2008: Place specific device cgroup hooks next to
		security_inode_{mknod,permission} rather than using
		the security hooks.
		Also remove most of the controls over tasks moving
		between cgroups and playing with the allow and deny
		permissions.
	Mar 13 2008: move the dev_cgroup support into
		capability hooks instead of having it
		as a separate ...
[ message continues ]

That's rather ugly-looking.  We can't use seq_file here?


--

[ message continues ]

You mean to add a Documentation/controller/devices.txt? ;)

--

[ message continues ]

I can do that, but then it will probably be cleaner if I split the
file into one for read and one for write.

Paul, did you have any plans of offering some sort of cft->read_seq()
helper?  Having both the cft-> helpers and the subsystem code play
with ->private fields and caching the cgroup isn't very palletable.

thanks,
-serge
--

[ message continues ]

Yes, it's on my TODO list. It should just be a pretty simple extension
of the existing read_map() support.

Paul
--

[ message continues ]

Ok, cool.  I can see about getting that done next week if you don't get
around to it, and convert the devices.allowed file to it.

thanks,
-serge
--

[ message continues ]

Can't you use selinux or something?

Or just fix the userland as this is for old-udev compatibility, only?

I don't know what this is, but it does not look like C...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]

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

Until the part of Miklos' user mounts patches go in which enforces MNT_NODEV
on mounts made by someone who is !capable(CAP_MKNOD), using capability bounding


Huh?

-serge
--

[ message continues ]

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

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
--

[ message continues ]

They help when multiple people add such SUBSYS things and
do not have to fight rejects.
--

[ message continues ]

If we go with the decision that properly isolated containers will
always require an LSM then I can go with that.  But IMO such a
decision needs agreement by all the players.  So far it seems there
is only calls from one objector.

Eric, I don't recall - was it your opinion that an LSM was an ok
--

[ message continues ]