aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/controllers/devices.txt
diff options
context:
space:
mode:
authorSerge E. Hallyn <serue@us.ibm.com>2008-04-29 04:00:10 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2008-04-29 11:06:09 -0400
commit08ce5f16ee466ffc5bf243800deeecd77d9eaf50 (patch)
tree8fb921137a677d463f11727dab7e683db426b810 /Documentation/controllers/devices.txt
parentd447ea2f30ec60370ddb99a668e5ac12995f043d (diff)
cgroups: implement device whitelist
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. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: fix may-be-used-uninitialized warning] Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> Acked-by: James Morris <jmorris@namei.org> Looks-good-to: Pavel Emelyanov <xemul@openvz.org> Cc: Daniel Hokka Zakrisson <daniel@hozac.com> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Paul Menage <menage@google.com> Cc: Balbir Singh <balbir@in.ibm.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/controllers/devices.txt')
-rw-r--r--Documentation/controllers/devices.txt48
1 files changed, 48 insertions, 0 deletions
diff --git a/Documentation/controllers/devices.txt b/Documentation/controllers/devices.txt
new file mode 100644
index 000000000000..4dcea42432c2
--- /dev/null
+++ b/Documentation/controllers/devices.txt
@@ -0,0 +1,48 @@
1Device Whitelist Controller
2
31. Description:
4
5Implement a cgroup to track and enforce open and mknod restrictions
6on device files. A device cgroup associates a device access
7whitelist with each cgroup. A whitelist entry has 4 fields.
8'type' is a (all), c (char), or b (block). 'all' means it applies
9to all types and all major and minor numbers. Major and minor are
10either an integer or * for all. Access is a composition of r
11(read), w (write), and m (mknod).
12
13The root device cgroup starts with rwm to 'all'. A child device
14cgroup gets a copy of the parent. Administrators can then remove
15devices from the whitelist or add new entries. A child cgroup can
16never receive a device access which is denied its parent. However
17when a device access is removed from a parent it will not also be
18removed from the child(ren).
19
202. User Interface
21
22An entry is added using devices.allow, and removed using
23devices.deny. For instance
24
25 echo 'c 1:3 mr' > /cgroups/1/devices.allow
26
27allows cgroup 1 to read and mknod the device usually known as
28/dev/null. Doing
29
30 echo a > /cgroups/1/devices.deny
31
32will remove the default 'a *:* mrw' entry.
33
343. Security
35
36Any task can move itself between cgroups. This clearly won't
37suffice, but we can decide the best way to adequately restrict
38movement as people get some experience with this. We may just want
39to require CAP_SYS_ADMIN, which at least is a separate bit from
40CAP_MKNOD. We may want to just refuse moving to a cgroup which
41isn't a descendent of the current one. Or we may want to use
42CAP_MAC_ADMIN, since we really are trying to lock down root.
43
44CAP_SYS_ADMIN is needed to modify the whitelist or move another
45task to a new cgroup. (Again we'll probably want to change that).
46
47A cgroup may not be granted more permissions than the cgroup's
48parent has.