From: "Mickaël Salaün" <mic@digikod.net>
To: Alejandro Colomar <alx@kernel.org>
Cc: "Günther Noack" <gnoack3000@gmail.com>, linux-man@vger.kernel.org
Subject: Re: [PATCH 3/3] man/man2/landlock_restrict_self.2, man/man7/landlock.7: Document audit logging (ABI v7)
Date: Wed, 8 Apr 2026 12:57:05 +0200 [thread overview]
Message-ID: <20260408.Vie1tai4eeco@digikod.net> (raw)
In-Reply-To: <adL41g1HDqiFMQzA@debian>
Hi!
On Mon, Apr 06, 2026 at 02:11:47AM +0200, Alejandro Colomar wrote:
> Hi Günther,
>
> I've applied patches 1/3 and 2/3. However, I've tried reading this
> a few times and still don't understand it well.
>
> On Sun, Mar 29, 2026 at 02:48:16PM +0200, Günther Noack wrote:
> > * Document the flags LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF,
> > LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF and
> > LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON.
> > * List these flags in the compatibility table in landlock.7
> >
> > The documentation text is copied from the kernel documentation,
> > originally authored by Mickaël Salaün in [1] and [2].
> >
> > Link[1]: <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/landlock.h?id=ead9079f75696a028aea8860787770c80eddb8f9>
> > Link[2]: <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/landlock.h?id=12bfcda73ac2cf3083c9d6d05724af92da3a4b4b>
> > Cc: Mickaël Salaün <mic@digikod.net>
> > Signed-off-by: Günther Noack <gnoack3000@gmail.com>
> > ---
> > man/man2/landlock_restrict_self.2 | 67 ++++++++++++++++++++++++++++++-
> > man/man7/landlock.7 | 6 ++-
> > 2 files changed, 70 insertions(+), 3 deletions(-)
> >
> > diff --git a/man/man2/landlock_restrict_self.2 b/man/man2/landlock_restrict_self.2
> > index 530ef9a4cd25..9e80a40ee4a4 100644
> > --- a/man/man2/landlock_restrict_self.2
> > +++ b/man/man2/landlock_restrict_self.2
> > @@ -68,8 +68,71 @@ is a Landlock ruleset file descriptor obtained with
> > and fully populated with a set of calls to
> > .BR landlock_add_rule (2).
> > .P
> > -.I flags
> > -must be 0.
> > +By default,
> > +denied accesses originating from programs that sandbox themselves
> > +are logged via the audit subsystem.
> > +Such events typically indicate unexpected behavior,
> > +such as bugs or exploitation attempts.
> > +However, to avoid excessive logging,
> > +access requests denied by a domain not created by the originating program
> > +are not logged by default.
> > +The rationale is that programs should know their own behavior,
> > +but not necessarily the behavior of other programs.
>
> If I understand this correctly, the default is to log after fork(2) or
> execve(2), but not before. Is that correct?
There is a distinctions before and after the first execve: once a
process sandboxes itself, by default, every denied operations are
logged, until it calls execve(2). At this point, in most cases, it is
not the same executable code, which means that this new program may not
be aware of the restrictions and may try to repeatedly do some denied
operations, which will not be logged by default
>
> > +This default configuration is suitable for most programs
> > +that sandbox themselves.
> > +For specific use cases,
> > +the following flags allow programs to modify this default logging behavior.
> > +.P
> > +The
> > +.B LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF
> > +and
> > +.B LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON
> > +flags apply to the newly created Landlock domain.
> > +.TP
> > +.B LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF
> > +Disables logging of denied accesses
> > +originating from the thread creating the Landlock domain,
> > +as well as its children,
> > +as long as they continue running the same executable code
> > +(i.e., without an intervening
> > +.BR execve (2)
> > +call).
>
> And if I understood this well, this changes the behavior so that fork(2)
> is ignored, so that logging will only be enabled at execve(2) but not at
> fork(2).
fork(2) and clone(2) are ignored, only execve(2) flips a bit and may
change the default behavior.
>
> > +This is intended for programs that execute unknown code
> > +without invoking
> > +.BR execve (2),
> > +such as script interpreters.
> > +Programs that only sandbox themselves should not set this flag,
> > +so users can be notified of unauthorized access attempts
> > +via system logs.
> > +.TP
> > +.B LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON
> > +Enables logging of denied accesses after an
> > +.BR execve (2)
> > +call,
>
> But this is the part that makes me think my previous understanding was
> wrong. I had understood that execve(3) already triggered logging. So
> what does this enable that wasn't enabled already?
LOG_NEW_EXEC_ON means that logging will not be disabled after execve(2).
>
>
> Have a lovely night!
> Alex
>
> > +providing visibility into unauthorized access attempts
> > +by newly executed programs within the created Landlock domain.
> > +This flag is recommended only when all potential executables
> > +in the domain are expected to comply with the access restrictions,
> > +as excessive audit log entries could make it more difficult
> > +to identify critical events.
> > +.TP
> > +.B LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF
> > +Disables logging of denied accesses
> > +originating from nested Landlock domains created by the caller
> > +or its descendants.
> > +This flag should be set according to runtime configuration,
> > +not hardcoded, to avoid suppressing important security events.
> > +It is useful for container runtimes or sandboxing tools
> > +that may launch programs which themselves create Landlock domains
> > +and could otherwise generate excessive logs.
> > +Unlike
> > +.BR LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF ,
> > +this flag only affects future nested domains,
> > +not the one being created.
> > +It can also be used with a
> > +.I ruleset_fd
> > +value of \-1 to mute subdomain logs
> > +without creating a domain.
> > .SH RETURN VALUE
> > On success,
> > .BR landlock_restrict_self ()
> > diff --git a/man/man7/landlock.7 b/man/man7/landlock.7
> > index 05664b3d7cba..bcf06ea30ad4 100644
> > --- a/man/man7/landlock.7
> > +++ b/man/man7/landlock.7
> > @@ -445,7 +445,7 @@ users should query the Landlock ABI version:
> > box;
> > ntb| ntb| lbx
> > nt| nt| lbx.
> > -ABI Kernel Newly introduced access rights
> > +ABI Kernel Newly introduced constants
> > _ _ _
> > 1 5.13 LANDLOCK_ACCESS_FS_EXECUTE
> > \^ \^ LANDLOCK_ACCESS_FS_WRITE_FILE
> > @@ -472,6 +472,10 @@ _ _ _
> > _ _ _
> > 6 6.12 LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET
> > \^ \^ LANDLOCK_SCOPE_SIGNAL
> > +_ _ _
> > +7 6.15 LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF
> > +\^ \^ LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON
> > +\^ \^ LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF
> > .TE
> > .P
> > Users should use the Landlock ABI version rather than the kernel version
> > --
> > 2.53.0
> >
>
> --
> <https://www.alejandro-colomar.es>
> Use port 80 (that is, <...:80/>).
next prev parent reply other threads:[~2026-04-08 10:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-29 12:48 [PATCH 0/3] landlock: Document audit logging Günther Noack
2026-03-29 12:48 ` [PATCH 1/3] man/man2/landlock*.2: Reorder errors alphabetically Günther Noack
2026-03-29 12:48 ` [PATCH 2/3] man/man2/landlock_create_ruleset.2: Document scoped field in struct landlock_ruleset_attr (ABI v6) Günther Noack
2026-03-29 12:48 ` [PATCH 3/3] man/man2/landlock_restrict_self.2, man/man7/landlock.7: Document audit logging (ABI v7) Günther Noack
2026-04-06 0:11 ` Alejandro Colomar
2026-04-08 10:57 ` Mickaël Salaün [this message]
2026-04-08 17:11 ` Alejandro Colomar
2026-04-08 18:03 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260408.Vie1tai4eeco@digikod.net \
--to=mic@digikod.net \
--cc=alx@kernel.org \
--cc=gnoack3000@gmail.com \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox