| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189 |
- .. SPDX-License-Identifier: GPL-2.0
- .. Copyright © 2025 Microsoft Corporation
- ================================
- Landlock: system-wide management
- ================================
- :Author: Mickaël Salaün
- :Date: January 2026
- Landlock can leverage the audit framework to log events.
- User space documentation can be found here:
- Documentation/userspace-api/landlock.rst.
- Audit
- =====
- Denied access requests are logged by default for a sandboxed program if `audit`
- is enabled. This default behavior can be changed with the
- sys_landlock_restrict_self() flags (cf.
- Documentation/userspace-api/landlock.rst). Landlock logs can also be masked
- thanks to audit rules. Landlock can generate 2 audit record types.
- Record types
- ------------
- AUDIT_LANDLOCK_ACCESS
- This record type identifies a denied access request to a kernel resource.
- The ``domain`` field indicates the ID of the domain that blocked the
- request. The ``blockers`` field indicates the cause(s) of this denial
- (separated by a comma), and the following fields identify the kernel object
- (similar to SELinux). There may be more than one of this record type per
- audit event.
- Example with a file link request generating two records in the same event::
- domain=195ba459b blockers=fs.refer path="/usr/bin" dev="vda2" ino=351
- domain=195ba459b blockers=fs.make_reg,fs.refer path="/usr/local" dev="vda2" ino=365
- The ``blockers`` field uses dot-separated prefixes to indicate the type of
- restriction that caused the denial:
- **fs.*** - Filesystem access rights (ABI 1+):
- - fs.execute, fs.write_file, fs.read_file, fs.read_dir
- - fs.remove_dir, fs.remove_file
- - fs.make_char, fs.make_dir, fs.make_reg, fs.make_sock
- - fs.make_fifo, fs.make_block, fs.make_sym
- - fs.refer (ABI 2+)
- - fs.truncate (ABI 3+)
- - fs.ioctl_dev (ABI 5+)
- **net.*** - Network access rights (ABI 4+):
- - net.bind_tcp - TCP port binding was denied
- - net.connect_tcp - TCP connection was denied
- **scope.*** - IPC scoping restrictions (ABI 6+):
- - scope.abstract_unix_socket - Abstract UNIX socket connection denied
- - scope.signal - Signal sending denied
- Multiple blockers can appear in a single event (comma-separated) when
- multiple access rights are missing. For example, creating a regular file
- in a directory that lacks both ``make_reg`` and ``refer`` rights would show
- ``blockers=fs.make_reg,fs.refer``.
- The object identification fields (path, dev, ino for filesystem; opid,
- ocomm for signals) depend on the type of access being blocked and provide
- context about what resource was involved in the denial.
- AUDIT_LANDLOCK_DOMAIN
- This record type describes the status of a Landlock domain. The ``status``
- field can be either ``allocated`` or ``deallocated``.
- The ``allocated`` status is part of the same audit event and follows
- the first logged ``AUDIT_LANDLOCK_ACCESS`` record of a domain. It identifies
- Landlock domain information at the time of the sys_landlock_restrict_self()
- call with the following fields:
- - the ``domain`` ID
- - the enforcement ``mode``
- - the domain creator's ``pid``
- - the domain creator's ``uid``
- - the domain creator's executable path (``exe``)
- - the domain creator's command line (``comm``)
- Example::
- domain=195ba459b status=allocated mode=enforcing pid=300 uid=0 exe="/root/sandboxer" comm="sandboxer"
- The ``deallocated`` status is an event on its own and it identifies a
- Landlock domain release. After such event, it is guarantee that the
- related domain ID will never be reused during the lifetime of the system.
- The ``domain`` field indicates the ID of the domain which is released, and
- the ``denials`` field indicates the total number of denied access request,
- which might not have been logged according to the audit rules and
- sys_landlock_restrict_self()'s flags.
- Example::
- domain=195ba459b status=deallocated denials=3
- Event samples
- --------------
- Here are two examples of log events (see serial numbers).
- In this example a sandboxed program (``kill``) tries to send a signal to the
- init process, which is denied because of the signal scoping restriction
- (``LL_SCOPED=s``)::
- $ LL_FS_RO=/ LL_FS_RW=/ LL_SCOPED=s LL_FORCE_LOG=1 ./sandboxer kill 1
- This command generates two events, each identified with a unique serial
- number following a timestamp (``msg=audit(1729738800.268:30)``). The first
- event (serial ``30``) contains 4 records. The first record
- (``type=LANDLOCK_ACCESS``) shows an access denied by the domain `1a6fdc66f`.
- The cause of this denial is signal scoping restriction
- (``blockers=scope.signal``). The process that would have receive this signal
- is the init process (``opid=1 ocomm="systemd"``).
- The second record (``type=LANDLOCK_DOMAIN``) describes (``status=allocated``)
- domain `1a6fdc66f`. This domain was created by process ``286`` executing the
- ``/root/sandboxer`` program launched by the root user.
- The third record (``type=SYSCALL``) describes the syscall, its provided
- arguments, its result (``success=no exit=-1``), and the process that called it.
- The fourth record (``type=PROCTITLE``) shows the command's name as an
- hexadecimal value. This can be translated with ``python -c
- 'print(bytes.fromhex("6B696C6C0031"))'``.
- Finally, the last record (``type=LANDLOCK_DOMAIN``) is also the only one from
- the second event (serial ``31``). It is not tied to a direct user space action
- but an asynchronous one to free resources tied to a Landlock domain
- (``status=deallocated``). This can be useful to know that the following logs
- will not concern the domain ``1a6fdc66f`` anymore. This record also summarize
- the number of requests this domain denied (``denials=1``), whether they were
- logged or not.
- .. code-block::
- type=LANDLOCK_ACCESS msg=audit(1729738800.268:30): domain=1a6fdc66f blockers=scope.signal opid=1 ocomm="systemd"
- type=LANDLOCK_DOMAIN msg=audit(1729738800.268:30): domain=1a6fdc66f status=allocated mode=enforcing pid=286 uid=0 exe="/root/sandboxer" comm="sandboxer"
- type=SYSCALL msg=audit(1729738800.268:30): arch=c000003e syscall=62 success=no exit=-1 [..] ppid=272 pid=286 auid=0 uid=0 gid=0 [...] comm="kill" [...]
- type=PROCTITLE msg=audit(1729738800.268:30): proctitle=6B696C6C0031
- type=LANDLOCK_DOMAIN msg=audit(1729738800.324:31): domain=1a6fdc66f status=deallocated denials=1
- Here is another example showcasing filesystem access control::
- $ LL_FS_RO=/ LL_FS_RW=/tmp LL_FORCE_LOG=1 ./sandboxer sh -c "echo > /etc/passwd"
- The related audit logs contains 8 records from 3 different events (serials 33,
- 34 and 35) created by the same domain `1a6fdc679`::
- type=LANDLOCK_ACCESS msg=audit(1729738800.221:33): domain=1a6fdc679 blockers=fs.write_file path="/dev/tty" dev="devtmpfs" ino=9
- type=LANDLOCK_DOMAIN msg=audit(1729738800.221:33): domain=1a6fdc679 status=allocated mode=enforcing pid=289 uid=0 exe="/root/sandboxer" comm="sandboxer"
- type=SYSCALL msg=audit(1729738800.221:33): arch=c000003e syscall=257 success=no exit=-13 [...] ppid=272 pid=289 auid=0 uid=0 gid=0 [...] comm="sh" [...]
- type=PROCTITLE msg=audit(1729738800.221:33): proctitle=7368002D63006563686F203E202F6574632F706173737764
- type=LANDLOCK_ACCESS msg=audit(1729738800.221:34): domain=1a6fdc679 blockers=fs.write_file path="/etc/passwd" dev="vda2" ino=143821
- type=SYSCALL msg=audit(1729738800.221:34): arch=c000003e syscall=257 success=no exit=-13 [...] ppid=272 pid=289 auid=0 uid=0 gid=0 [...] comm="sh" [...]
- type=PROCTITLE msg=audit(1729738800.221:34): proctitle=7368002D63006563686F203E202F6574632F706173737764
- type=LANDLOCK_DOMAIN msg=audit(1729738800.261:35): domain=1a6fdc679 status=deallocated denials=2
- Event filtering
- ---------------
- If you get spammed with audit logs related to Landlock, this is either an
- attack attempt or a bug in the security policy. We can put in place some
- filters to limit noise with two complementary ways:
- - with sys_landlock_restrict_self()'s flags if we can fix the sandboxed
- programs,
- - or with audit rules (see :manpage:`auditctl(8)`).
- Additional documentation
- ========================
- * `Linux Audit Documentation`_
- * Documentation/userspace-api/landlock.rst
- * Documentation/security/landlock.rst
- * https://landlock.io
- .. Links
- .. _Linux Audit Documentation:
- https://github.com/linux-audit/audit-documentation/wiki
|