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

[PATCH] cgroups: implement device whitelist (v4)
type: item
description: 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. The parsing of devices.allow/deny needs to be cleaned up a bit and Documented. I'd like to get an idea whether this approach is otherwise acceptable. Changelog: 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. Switch to major:minor format. Rename devcg to 'devices' to conform to cgroup naming. 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, d…
creator: serue
date: 2008-03-17T18:07:22-00:00

Re: [PATCH] cgroups: implement device whitelist (v4)
type: item
description: On Mon, 17 Mar 2008, Serge E. Hallyn wrote: > 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). Acked-by: James Morris <jmorris@namei.org> -- James Morris <jmorris@namei.org> _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: James Morris
date: 2008-03-18T04:17:53-00:00

Re: [PATCH] cgroups: implement device whitelist (v4)
type: item
description: Serge E. Hallyn wrote: > 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. > > The parsing of devices.allow/deny needs to be cleaned up a bit and > Documented. I'd like to get an idea whether this approach is otherwise > acceptable. > > Changelog: > 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. > Switch to major:minor format. > Rename devcg to 'devices' to conform to cgroup naming. > Mar 13 2008: move the dev_cgroup support into > capability ho…
creator: Li Zefan
date: 2008-03-18T05:15:05-00:00

Re: [PATCH] cgroups: implement device whitelist (v4)
type: item
description: Serge E. Hallyn wrote: > 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. > > The parsing of devices.allow/deny needs to be cleaned up a bit and > Documented. I'd like to get an idea whether this approach is otherwise > acceptable. > > Changelog: > 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. > Switch to major:minor format. > Rename devcg to 'devices' to conform to cgroup naming. > Mar 13 2008: move the dev_cgroup support into > capability ho…
creator: Pavel Emelianov
date: 2008-03-18T07:57:03-00:00

Re: [PATCH] cgroups: implement device whitelist (v4)
type: item
description: Quoting Li Zefan (lizf@cn.fujitsu.com): > Serge E. Hallyn wrote: > > 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. > > > > The parsing of devices.allow/deny needs to be cleaned up a bit and > > Documented. I'd like to get an idea whether this approach is otherwise > > acceptable. > > > > Changelog: > > 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. > > Switch to major:mino…
creator: serue
date: 2008-03-18T14:10:45-00:00