요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Security
devices.rst:40-56Capability와 parent permission 상한을 정리합니다.
Hierarchy
devices.rst:57-132Deny propagation, local exception 재검증과 내부 behavior를 다룹니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
===========================
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
/ \
B
group behavior exceptions
A allow "b 8:* rwm", "c 116:1 rw"
B deny "c 1:3 rwm", "c 116:2 rwm", "b 3:* rwm"
If a device is denied in group A::
# echo "c 116:* r" > A/devices.deny
it'll propagate down and after revalidating B's entries, the whitelist entry
"c 116:2 rwm" will be removed::
group whitelist entries denied devices
A all "b 8:* rwm", "c 116:* rw"
B "c 1:3 rwm", "b 3:* rwm" all the rest
In case parent's exceptions change and local exceptions are not allowed
anymore, they'll be deleted.
Notice that new whitelist entries will not be propagated::
A
/ \
B
group whitelist entries denied devices
A "c 1:3 rwm", "c 1:5 r" all the rest
B "c 1:3 rwm", "c 1:5 r" all the rest
when adding ``c *:3 rwm``::
# echo "c *:3 rwm" >A/devices.allow
the result::
group whitelist entries denied devices
A "c *:3 rwm", "c 1:5 r" all the rest
B "c 1:3 rwm", "c 1:5 r" all the rest
but now it'll be possible to add new entries to B::
# echo "c 2:3 rwm" >B/devices.allow
# echo "c 50:3 r" >B/devices.allow
or even::
# echo "c *:3 rwm" >B/devices.allow
Allowing or denying all by writing 'a' to devices.allow or devices.deny will
not be possible once the device cgroups has children.
4.1 Hierarchy (internal implementation)
---------------------------------------
device cgroups is implemented internally using a behavior (ALLOW, DENY) and a
list of exceptions. The internal state is controlled using the same user
interface to preserve compatibility with the previous whitelist-only
implementation. Removal or addition of exceptions that will reduce the access
to devices will be propagated down the hierarchy.
For every propagated exception, the effective rules will be re-evaluated based
on current parent's access rules.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Device whitelist model
1-20Device Whitelist Controller는 device file의 `open`과 `mknod` 제한을 추적하고 강제하는 cgroup controller입니다. 각 device cgroup에는 access whitelist가 연결됩니다.
Whitelist entry를 구성하는 네 field입니다.
`a`는 모든 type과 모든 major·minor에 적용됩니다. Root device cgroup은 기본적으로 `a *:* rwm`, 즉 모든 device에 read/write/mknod 권한을 가집니다.
Child는 parent whitelist 사본에서 시작하지만 parent보다 넓은 권한을 가질 수 없습니다.
devices.allow와 devices.deny
21-39`devices.allow`에 entry를 쓰면 허용 규칙을 추가하고 `devices.deny`에 쓰면 제거합니다. 다음 명령은 cgroup 1이 일반적으로 `/dev/null`인 character device `1:3`을 read하고 `mknod`하도록 허용합니다.
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
예제 write가 effective whitelist에 미치는 영향입니다.
Task 이동과 capability
40-56문서 작성 당시 task가 스스로 cgroup 사이를 이동할 수 있다는 점은 충분한 보안 경계가 아니었습니다. 이동을 `CAP_SYS_ADMIN`으로 제한하거나 current cgroup의 descendant로만 허용하거나, root confinement 성격에 맞춰 `CAP_MAC_ADMIN`을 쓰는 방안이 논의됩니다.
현재 문서가 명시하는 권한과 변하지 않는 계층 제약입니다.
`CAP_SYS_ADMIN`은 whitelist 수정과 다른 task를 새 cgroup으로 이동하는 데 필요합니다. 어떤 경우에도 cgroup은 parent가 가진 것보다 더 많은 device permission을 부여받을 수 없습니다.
Deny 전파와 allow 비전파
57-122Device cgroup hierarchy는 child가 parent보다 넓은 권한을 갖지 못하게 유지합니다. `devices.deny`에 entry가 쓰일 때마다 모든 descendant whitelist에서 그 access를 제거하고 locally set entry를 parent의 새 effective rule에 맞춰 다시 검증합니다.
A
/ \
B
group behavior exceptions
A allow "b 8:* rwm", "c 116:1 rw"
B deny "c 1:3 rwm", "c 116:2 rwm", "b 3:* rwm"
If a device is denied in group A::
# echo "c 116:* r" > A/devices.deny
it'll propagate down and after revalidating B's entries, the whitelist entry
"c 116:2 rwm" will be removed::
group whitelist entries denied devices
A all "b 8:* rwm", "c 116:* rw"
B "c 1:3 rwm", "b 3:* rwm" all the rest
A에서 `c 116:* r`을 deny하면 B의 충돌하는 local exception도 제거됩니다.
원문 A/B 예제의 revalidation 결과입니다.
Parent exception이 변해 child의 local exception이 더 이상 허용되지 않으면 그 entry를 삭제합니다. 반대로 parent에 새 allow entry를 추가해도 기존 child whitelist에는 자동 전파하지 않습니다.
A
/ \
B
group whitelist entries denied devices
A "c 1:3 rwm", "c 1:5 r" all the rest
B "c 1:3 rwm", "c 1:5 r" all the rest
when adding ``c *:3 rwm``::
# echo "c *:3 rwm" >A/devices.allow
the result::
group whitelist entries denied devices
A "c *:3 rwm", "c 1:5 r" all the rest
B "c 1:3 rwm", "c 1:5 r" all the rest
but now it'll be possible to add new entries to B::
# echo "c 2:3 rwm" >B/devices.allow
# echo "c 50:3 r" >B/devices.allow
or even::
# echo "c *:3 rwm" >B/devices.allow
A의 권한 확장은 B의 현재 whitelist를 바꾸지 않지만 B가 같은 범위 안에서 새 entry를 추가할 수 있게 합니다.
Device cgroup에 child가 생긴 뒤에는 `devices.allow` 또는 `devices.deny`에 `a`를 써서 전체를 한 번에 allow/deny할 수 없습니다.
ALLOW·DENY behavior와 exception list
123-132내부 구현은 `ALLOW` 또는 `DENY` behavior와 exception list를 사용합니다. 이전 whitelist-only interface와 compatibility를 유지하기 위해 같은 user interface로 내부 state를 제어합니다.
Access를 줄이는 exception 변화만 descendant에 전파합니다.
전파된 각 exception마다 current parent access rule을 기준으로 descendant의 effective rule을 다시 계산합니다.
Rules and interface
devices.rst:1-39Device rule field와 allow/deny write를 설명합니다.