Re: [PATCH 3/3] man/man2/landlock_restrict_self.2, man/man7/landlock.7: Document audit logging (ABI v7)

Alejandro Colomar
2026-04-08T17:11:33Z

[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]

Hi Mickaël!

On 2026-04-08T12:57:05+0200, Mickaël Salaün wrote:
> > > @@ -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

Oh, true, I got it reversed! That's probably the source of my
misunderstanding. :)

So, by default, before execve(2) we log, and after it we don't.

> > > +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.

So, this is the reverse of the above. Before execve(2), _EXEC_OFF
doesn't log, and it logs after it.

> > > +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).

Okay, and _EXEC_ON means log before and after. Sounds good now in my
head.

Cheers,
Alex

--
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]