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

[Tingmao Wang]

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?

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