[RFC PATCH 1/6] landlock: Add a place for flags to layer rules

[Mickaël Salaün]

On Sat, Sep 27, 2025 at 04:43:50PM +0100, Tingmao Wang wrote:
> On 9/24/25 10:20, Mickaël Salaün wrote:
> > On Mon, Sep 22, 2025 at 12:52:19AM +0100, Tingmao Wang wrote:
> >> [...]
> >> "accumulative".  Therefore if this (different "quietness" for different
> >> access bits) becomes a strong need, we should probably consider some way
> >> of implementing it, rather than expecting a sandboxer to do this two-layer
> >> hack.  (But implementing this does have the potential to result in needing
> >> to have a (number of access bits) x (number of layers) matrix...)
> > 
> > Yes, that will indeed increase the size of rules, which is why I'm not
> > sure if it worth it.
> 
> In addition to the size of each rule, another concern is that we would
> need another layer_mask_t[LANDLOCK_NUM_ACCESS_FS] matrix on the stack in
> order to correctly accumulate quiet bits when multiple access bits are
> requested, and the quiet bits are only set on some of them / spread out
> between different objects.  For example, for this 1 layer domain:
> 
> /         quiet: r
>   /etc    quiet: w
> 
> request: /etc/file rw
>     # This should not audit log, but if we only keep one accumulated bit
>     # per layer, we would not be able to tell that all access bits are
>     # eventually "covered" by quiet flags.
> 
> The alternative approach you suggested below would get rid of this
> situation as well.
> 
> > 
> > The alternative I was thinking about is to only increase the size of
> > struct landlock_ruleset (which would be negligible) to include sets of
> > quiet access rights.  A request to such access right *on* a quiet object
> > would never be logged.  I think this approach is flexible enough and
> > doesn't increase much the complexity.  This would also be useful to not
> > log access rights that don't have associated rules (e.g. scopes), and
> > then no identified objects.  To avoid the kind of hack you pointed out,
> > this feature should probably be part of this patch series though.  What
> > do you think?
> 
> This seems reasonable to me, especially if we don't think that having
> separate quiet access bit controls for each object would be a common need.
> Although if for some reason such control is needed, one might still be
> tempted to use the kind of two layer hack I mentioned.  Maybe some program
> would like to quiet reads globally but only quiet writes to /run...?
> 
> But maybe later on when we get to have supervised domains, the supervisor
> can tell Landlock whether to audit log or not for individual denied
> requests, or do such logging itself, therefore offering fine-grained
> control without hacks, and could potentially be more flexible e.g. only
> log once per request per process, etc.
> 
> I think the most obvious way to implement this is to add a field to struct
> landlock_ruleset_attr, and landlock_create_ruleset would use the passed in
> size to determine if the quiet access bits field should be read or not?

Yes

> 
> Also, do we want to consider calling this something else instead, like
> "suppress_audit"?

Quiet is simpler (similar to the LANDLOCK_RESTRICT_SELF_LOG_* flags) and
if we get other ways to log actions this will also be used.  For the
supervisor case, that would be useful to not forward a request to the
supervisor.  The *_LOG_* flags could be used the same way too (even if
"LOG" may be a subset of the supervisor capabilities).  Do you think
that would be OK?  Dedicated flags would be more flexible but also a bit
more complex.  Is it worth it?  In any case, the semantic and need
should be quite similar.