OpenVZ Forum - RDF feed
type: channel
items: [PATCH 1/1] cgroups: implement device whitelist (v5)
items: Re: [PATCH 1/1] cgroups: implement device whitelist (v5)

[PATCH 1/1] cgroups: implement device whitelist (v5)
type: item
description: This version differs from v4 only in that it addresses Li Zefan's comments on v4. 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 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 security module. Support root_plug with devcg. Note that due to this change, devcg will not be enforcing if the dummy module is loaded, or if selinux is loaded without capabilities. Mar 12…
creator: serue
date: 2008-03-18T16:56:10-00:00

Re: [PATCH 1/1] cgroups: implement device whitelist (v5)
type: item
description: Hi Serge, Some minor nits in the patch. Serge E. Hallyn wrote: > This version differs from v4 only in that it addresses Li Zefan's comments > on > v4. > > 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 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 security module. > Support ro…
creator: Daniel Hokka Zakrisso
date: 2008-03-19T16:00:54-00:00

Re: [PATCH 1/1] cgroups: implement device whitelist (v5)
type: item
description: Quoting Daniel Hokka Zakrisson (daniel@hozac.com): > Hi Serge, > > Some minor nits in the patch. > > Serge E. Hallyn wrote: > > This version differs from v4 only in that it addresses Li Zefan's comments > > on > > v4. > > > > 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 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…
creator: serue
date: 2008-03-19T20:48:03-00:00