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>