Documentation/admin-guide/cgroup-v1/devices.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/cgroup-v1/devices.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/cgroup-v1/devices.rst
Extension
.rst
Size
4549 bytes
Lines
133
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

===========================
Device Whitelist Controller
===========================

1. 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 device
cgroup gets a copy of the parent.  Administrators can then remove
devices from the whitelist or add new entries.  A child cgroup can
never receive a device access which is denied by its parent.

2. User Interface
=================

An entry is added using devices.allow, and removed using
devices.deny.  For instance::

	echo 'c 1:3 mr' > /sys/fs/cgroup/1/devices.allow

allows cgroup 1 to read and mknod the device usually known as
/dev/null.  Doing::

	echo a > /sys/fs/cgroup/1/devices.deny

will remove the default 'a *:* rwm' entry. Doing::

	echo a > /sys/fs/cgroup/1/devices.allow

will add the 'a *:* rwm' entry to the whitelist.

3. Security
===========

Any task can move itself between cgroups.  This clearly won't
suffice, but we can decide the best way to adequately restrict
movement as people get some experience with this.  We may just want
to require CAP_SYS_ADMIN, which at least is a separate bit from
CAP_MKNOD.  We may want to just refuse moving to a cgroup which
isn't a descendant of the current one.  Or we may want to use
CAP_MAC_ADMIN, since we really are trying to lock down root.

CAP_SYS_ADMIN is needed to modify the whitelist or move another
task to a new cgroup.  (Again we'll probably want to change that).

A cgroup may not be granted more permissions than the cgroup's
parent has.

4. Hierarchy
============

device cgroups maintain hierarchy by making sure a cgroup never has more
access permissions than its parent.  Every time an entry is written to
a cgroup's devices.deny file, all its children will have that entry removed
from their whitelist and all the locally set whitelist entries will be
re-evaluated.  In case one of the locally set whitelist entries would provide
more access than the cgroup's parent, it'll be removed from the whitelist.

Example::

      A
     / \

Annotation

Implementation Notes