요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
.. Copyright © 2017-2020 Mickaël Salaün <[email protected]>
.. Copyright © 2019-2020 ANSSI
==================================
Landlock LSM: kernel documentation
==================================
:Author: Mickaël Salaün
:Date: March 2025
Landlock's goal is to create scoped access-control (i.e. sandboxing). To
harden a whole system, this feature should be available to any process,
including unprivileged ones. Because such a process may be compromised or
backdoored (i.e. untrusted), Landlock's features must be safe to use from the
kernel and other processes point of view. Landlock's interface must therefore
expose a minimal attack surface.
Landlock is designed to be usable by unprivileged processes while following the
system security policy enforced by other access control mechanisms (e.g. DAC,
LSM). A Landlock rule shall not interfere with other access-controls enforced
on the system, only add more restrictions.
Any user can enforce Landlock rulesets on their processes. They are merged and
evaluated against inherited rulesets in a way that ensures that only more
constraints can be added.
User space documentation can be found here:
Documentation/userspace-api/landlock.rst.
Guiding principles for safe access controls
===========================================
* A Landlock rule shall be focused on access control on kernel objects instead
of syscall filtering (i.e. syscall arguments), which is the purpose of
seccomp-bpf.
* To avoid multiple kinds of side-channel attacks (e.g. leak of security
policies, CPU-based attacks), Landlock rules shall not be able to
programmatically communicate with user space.
* Kernel access check shall not slow down access request from unsandboxed
processes.
* Computation related to Landlock operations (e.g. enforcing a ruleset) shall
only impact the processes requesting them.
* Resources (e.g. file descriptors) directly obtained from the kernel by a
sandboxed process shall retain their scoped accesses (at the time of resource
acquisition) whatever process uses them.
Cf. `File descriptor access rights`_.
* Access denials shall be logged according to system and Landlock domain
configurations. Log entries must contain information about the cause of the
denial and the owner of the related security policy. Such log generation
should have a negligible performance and memory impact on allowed requests.
Design choices
==============
Inode access rights
-------------------
All access rights are tied to an inode and what can be accessed through it.
Reading the content of a directory does not imply to be allowed to read the
content of a listed inode. Indeed, a file name is local to its parent
directory, and an inode can be referenced by multiple file names thanks to
(hard) links. Being able to unlink a file only has a direct impact on the
directory, not the unlinked inode. This is the reason why
``LANDLOCK_ACCESS_FS_REMOVE_FILE`` or ``LANDLOCK_ACCESS_FS_REFER`` are not
allowed to be tied to files but only to directories.
File descriptor access rights
-----------------------------
Access rights are checked and tied to file descriptors at open time. The
underlying principle is that equivalent sequences of operations should lead to
the same results, when they are executed under the same Landlock domain.
Taking the ``LANDLOCK_ACCESS_FS_TRUNCATE`` right as an example, it may be
allowed to open a file for writing without being allowed to
:manpage:`ftruncate` the resulting file descriptor if the related file
hierarchy doesn't grant that access right. The following sequences of
operations have the same semantic and should then have the same result:
* ``truncate(path);``
* ``int fd = open(path, O_WRONLY); ftruncate(fd); close(fd);``
Similarly to file access modes (e.g. ``O_RDWR``), Landlock access rights
attached to file descriptors are retained even if they are passed between
processes (e.g. through a Unix domain socket). Such access rights will then be
enforced even if the receiving process is not sandboxed by Landlock. Indeed,
this is required to keep access controls consistent over the whole system, and
this avoids unattended bypasses through file descriptor passing (i.e. confused
deputy attack).
Tests
=====
Userspace tests for backward compatibility, ptrace restrictions and filesystem
support can be found here: `tools/testing/selftests/landlock/`_.
Kernel structures
=================
Object
------
.. kernel-doc:: security/landlock/object.h
:identifiers:
Filesystem
----------
.. kernel-doc:: security/landlock/fs.h
:identifiers:
Ruleset and domain
------------------
A domain is a read-only ruleset tied to a set of subjects (i.e. tasks'
credentials). Each time a ruleset is enforced on a task, the current domain is
duplicated and the ruleset is imported as a new layer of rules in the new
domain. Indeed, once in a domain, each rule is tied to a layer level. To
grant access to an object, at least one rule of each layer must allow the
requested action on the object. A task can then only transit to a new domain
that is the intersection of the constraints from the current domain and those
of a ruleset provided by the task.
The definition of a subject is implicit for a task sandboxing itself, which
makes the reasoning much easier and helps avoid pitfalls.
.. kernel-doc:: security/landlock/ruleset.h
:identifiers:
Additional documentation
========================
* Documentation/userspace-api/landlock.rst
* Documentation/admin-guide/LSM/landlock.rst
* https://landlock.io
.. Links
.. _tools/testing/selftests/landlock/:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock/
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
목표와 단조 증가하는 제한
1-30Landlock의 목표는 범위가 제한된 접근 제어, 즉 sandboxing을 만드는 것이다. 시스템 전체를 강화하려면 권한 없는 프로세스를 포함한 모든 프로세스가 이 기능을 사용할 수 있어야 한다. 호출자가 이미 침해되었거나 backdoor가 있는 신뢰할 수 없는 프로세스일 수도 있으므로, Landlock 기능은 커널과 다른 프로세스의 관점에서도 안전해야 하고 인터페이스의 공격 표면을 최소화해야 한다.
Landlock은 DAC와 다른 LSM이 강제하는 시스템 보안 정책을 따르면서 권한 없는 프로세스도 사용할 수 있도록 설계되었다. Landlock 규칙은 기존 접근 제어를 방해하거나 권한을 넓히지 않고 제한만 추가한다. 어떤 사용자든 자기 프로세스에 ruleset을 강제할 수 있으며, 새 ruleset은 상속된 ruleset과 병합·평가되어 제약이 단조롭게 늘어나기만 한다.
사용자 공간 인터페이스의 구체적인 사용법은 `Documentation/userspace-api/landlock.rst`에 있다.
프로세스가 스스로 sandbox를 좁혀도 기존 정책보다 권한이 넓어지지 않는다.
.. SPDX-License-Identifier: GPL-2.0
.. Copyright © 2017-2020 Mickaël Salaün <[email protected]>
.. Copyright © 2019-2020 ANSSI
==================================
Landlock LSM: kernel documentation
==================================
:Author: Mickaël Salaün
:Date: March 2025
Landlock's goal is to create scoped access-control (i.e. sandboxing). To
harden a whole system, this feature should be available to any process,
including unprivileged ones. Because such a process may be compromised or
backdoored (i.e. untrusted), Landlock's features must be safe to use from the
kernel and other processes point of view. Landlock's interface must therefore
expose a minimal attack surface.
Landlock is designed to be usable by unprivileged processes while following the
system security policy enforced by other access control mechanisms (e.g. DAC,
LSM). A Landlock rule shall not interfere with other access-controls enforced
on the system, only add more restrictions.
Any user can enforce Landlock rulesets on their processes. They are merged and
evaluated against inherited rulesets in a way that ensures that only more
constraints can be added.
User space documentation can be found here:
Documentation/userspace-api/landlock.rst.
안전한 접근 제어의 원칙
31-52Landlock 규칙은 syscall 인자 필터링이 아니라 커널 객체의 접근 제어에 집중한다. syscall filtering은 seccomp-bpf의 역할이다. 보안 정책 누출이나 CPU 기반 공격 같은 side channel을 피하기 위해 규칙이 프로그램 방식으로 사용자 공간과 통신할 수 없어야 한다.
sandbox되지 않은 프로세스의 접근 요청은 Landlock 검사 때문에 느려지지 않아야 하고, ruleset 강제 같은 계산 비용은 그 동작을 요청한 프로세스에만 영향을 주어야 한다. sandbox 프로세스가 커널에서 직접 얻은 파일 설명자 같은 자원은 어느 프로세스가 사용하더라도 획득 시점의 범위 제한을 유지해야 한다.
접근 거부는 시스템과 Landlock domain 구성에 따라 기록해야 한다. 로그에는 거부 원인과 관련 보안 정책의 소유자 정보가 들어가야 하며, 허용되는 요청에 대한 성능과 메모리 비용은 무시할 수 있을 정도로 작아야 한다.
정책 표현과 성능, 자원 전달, 감사 기록에 대한 경계를 정한다.
Guiding principles for safe access controls
===========================================
* A Landlock rule shall be focused on access control on kernel objects instead
of syscall filtering (i.e. syscall arguments), which is the purpose of
seccomp-bpf.
* To avoid multiple kinds of side-channel attacks (e.g. leak of security
policies, CPU-based attacks), Landlock rules shall not be able to
programmatically communicate with user space.
* Kernel access check shall not slow down access request from unsandboxed
processes.
* Computation related to Landlock operations (e.g. enforcing a ruleset) shall
only impact the processes requesting them.
* Resources (e.g. file descriptors) directly obtained from the kernel by a
sandboxed process shall retain their scoped accesses (at the time of resource
acquisition) whatever process uses them.
Cf. `File descriptor access rights`_.
* Access denials shall be logged according to system and Landlock domain
configurations. Log entries must contain information about the cause of the
denial and the owner of the related security policy. Such log generation
should have a negligible performance and memory impact on allowed requests.
inode 접근 권한
53-67모든 Landlock 접근 권한은 inode와 그 inode를 통해 접근할 수 있는 대상에 연결된다. 디렉터리 내용을 읽을 수 있다고 해서 그 목록에 나타난 inode의 내용을 읽을 수 있는 것은 아니다. 파일 이름은 상위 디렉터리에 국한되고 하나의 inode는 hard link로 여러 파일 이름에서 참조될 수 있기 때문이다.
파일을 unlink할 수 있는 권한은 직접적으로 디렉터리에 영향을 주며 unlink된 inode 자체에 대한 권한은 아니다. 따라서 `LANDLOCK_ACCESS_FS_REMOVE_FILE`과 `LANDLOCK_ACCESS_FS_REFER`는 파일에 연결할 수 없고 디렉터리에만 연결할 수 있다.
이름 조작 권한과 inode 내용 접근 권한을 구분한다.
Design choices
==============
Inode access rights
-------------------
All access rights are tied to an inode and what can be accessed through it.
Reading the content of a directory does not imply to be allowed to read the
content of a listed inode. Indeed, a file name is local to its parent
directory, and an inode can be referenced by multiple file names thanks to
(hard) links. Being able to unlink a file only has a direct impact on the
directory, not the unlinked inode. This is the reason why
``LANDLOCK_ACCESS_FS_REMOVE_FILE`` or ``LANDLOCK_ACCESS_FS_REFER`` are not
allowed to be tied to files but only to directories.
파일 설명자 접근 권한
68-91접근 권한은 파일을 여는 시점에 검사되고 파일 설명자에 결합된다. 같은 Landlock domain에서 의미상 동등한 연산 순서는 같은 결과를 내야 한다는 원칙을 따른다.
`LANDLOCK_ACCESS_FS_TRUNCATE`를 예로 들면, 관련 파일 계층이 truncate 권한을 부여하지 않았더라도 쓰기용 open 자체는 허용될 수 있다. 그러나 그 결과 파일 설명자에 `ftruncate`를 호출하는 것은 거부된다. 따라서 `truncate(path)`와 `open(path, O_WRONLY)` 뒤 `ftruncate(fd)`를 수행하는 순서는 의미가 같고 결과도 같아야 한다.
`O_RDWR` 같은 파일 접근 모드와 마찬가지로 파일 설명자에 붙은 Landlock 권한은 Unix domain socket 등으로 다른 프로세스에 전달해도 유지된다. 수신 프로세스가 Landlock sandbox 안에 있지 않더라도 이 권한을 강제해야 시스템 전체의 접근 제어가 일관되고, 파일 설명자 전달을 이용한 confused deputy 우회를 막을 수 있다.
경로 기반 호출과 파일 설명자 기반 호출은 같은 정책 결과를 내야 한다.
File descriptor access rights
-----------------------------
Access rights are checked and tied to file descriptors at open time. The
underlying principle is that equivalent sequences of operations should lead to
the same results, when they are executed under the same Landlock domain.
Taking the ``LANDLOCK_ACCESS_FS_TRUNCATE`` right as an example, it may be
allowed to open a file for writing without being allowed to
:manpage:`ftruncate` the resulting file descriptor if the related file
hierarchy doesn't grant that access right. The following sequences of
operations have the same semantic and should then have the same result:
* ``truncate(path);``
* ``int fd = open(path, O_WRONLY); ftruncate(fd); close(fd);``
Similarly to file access modes (e.g. ``O_RDWR``), Landlock access rights
attached to file descriptors are retained even if they are passed between
processes (e.g. through a Unix domain socket). Such access rights will then be
enforced even if the receiving process is not sandboxed by Landlock. Indeed,
this is required to keep access controls consistent over the whole system, and
this avoids unattended bypasses through file descriptor passing (i.e. confused
deputy attack).
테스트, 객체, ruleset과 domain
92-130하위 호환성, ptrace 제한, 파일시스템 지원을 확인하는 사용자 공간 테스트는 `tools/testing/selftests/landlock/`에 있다. 커널 구조 문서는 `security/landlock/object.h`의 object와 `security/landlock/fs.h`의 filesystem kernel-doc에서 가져온다.
domain은 subject 집합, 즉 task credential 집합에 연결된 읽기 전용 ruleset이다. task에 ruleset을 강제할 때마다 현재 domain을 복제하고 새 ruleset을 새 domain의 rule layer로 가져온다. domain 안의 각 규칙은 layer 수준에 연결된다.
객체 접근을 허용하려면 모든 layer마다 요청 동작을 허용하는 규칙이 최소 하나씩 있어야 한다. 따라서 task는 현재 domain의 제약과 자신이 제공한 ruleset 제약의 교집합인 새 domain으로만 이동할 수 있다. task가 자신을 sandbox하는 경우 subject 정의가 암시적이어서 추론이 쉬워지고 실수를 피할 수 있다. ruleset 구조의 상세 정의는 `security/landlock/ruleset.h` kernel-doc에 있다.
모든 layer가 요청을 허용해야 최종 접근이 허용된다.
Tests
=====
Userspace tests for backward compatibility, ptrace restrictions and filesystem
support can be found here: `tools/testing/selftests/landlock/`_.
Kernel structures
=================
Object
------
.. kernel-doc:: security/landlock/object.h
:identifiers:
Filesystem
----------
.. kernel-doc:: security/landlock/fs.h
:identifiers:
Ruleset and domain
------------------
A domain is a read-only ruleset tied to a set of subjects (i.e. tasks'
credentials). Each time a ruleset is enforced on a task, the current domain is
duplicated and the ruleset is imported as a new layer of rules in the new
domain. Indeed, once in a domain, each rule is tied to a layer level. To
grant access to an object, at least one rule of each layer must allow the
requested action on the object. A task can then only transit to a new domain
that is the intersection of the constraints from the current domain and those
of a ruleset provided by the task.
The definition of a subject is implicit for a task sandboxing itself, which
makes the reasoning much easier and helps avoid pitfalls.
.. kernel-doc:: security/landlock/ruleset.h
:identifiers:
추가 문서와 selftest 링크
131-140추가 자료로 사용자 공간 API 문서 `Documentation/userspace-api/landlock.rst`, 관리자용 `Documentation/admin-guide/LSM/landlock.rst`, 프로젝트 사이트 `https://landlock.io`를 참조할 수 있다. selftest 링크는 stable Linux 저장소의 `tools/testing/selftests/landlock/` 디렉터리를 가리킨다.
Additional documentation
========================
* Documentation/userspace-api/landlock.rst
* Documentation/admin-guide/LSM/landlock.rst
* https://landlock.io
.. Links
.. _tools/testing/selftests/landlock/:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock/
요약·해설
landlock.rst:1-140Landlock의 제한 누적 모델, inode와 파일 설명자 권한, layer 기반 domain 평가 및 커널 구조를 설명합니다.