[RFC PATCH v1 0/5] Landlock tracepoints

[Tingmao Wang]

On 5/23/25 17:57, Mickaël Salaün wrote:
> Hi,
> 
> This series adds two tracepoints to Landlock, one tied to rule addition,
> and another to rule checking.  With these new tracepoints, we can see
> all steps leading to an access decision.  They can be directly used with
> /sys/kernel/tracing/events/landlock/* or attached by eBPF programs to
> get a more complete view of Landlock internals.
> 
> This new feature is useful to trouble shoot policy issues, and it should
> also limit the need for custom debugging kernel code when developing new
> Landlock features.
> 
> Landlock already has audit support, which enables us to log denied
> access requests.  Audit is useful to identify security issues or sandbox
> misconfiguration.  However, it might not be enough to debug Landlock
> policies.  The main differences with audit events is that traces are
> disabled by default, can be very verbose, and can be filtered according
> to process and Landlock properties (e.g. domain ID).
> 
> As for audit, this tracing feature may expose sensitive information and
> must then only be accessible to the system administrator.
> 
> This RFC only fully supports filesystem rules but the next series will
> also support network rules.  Tests are also missing for now.
> 
> Regards,
> 
> Mickaël Salaün (5):
>    landlock: Rename landlock_id to landlock_rule_ref
>    landlock: Merge landlock_find_rule() into landlock_unmask_layers()
>    tracing: Add __print_untrusted_str()
>    landlock: Add landlock_add_rule_fs tracepoint
>    landlock: Add landlock_check_rule tracepoint
> 
>   MAINTAINERS                                |   1 +
>   include/linux/trace_events.h               |   3 +
>   include/trace/events/landlock.h            | 124 ++++++++++++++
>   include/trace/stages/stage3_trace_output.h |   4 +
>   include/trace/stages/stage7_class_define.h |   1 +
>   kernel/trace/trace_output.c                |  40 +++++
>   security/landlock/Makefile                 |  11 +-
>   security/landlock/fs.c                     | 178 +++++++++++++--------
>   security/landlock/fs.h                     |   3 +
>   security/landlock/net.c                    |  18 +--
>   security/landlock/ruleset.c                |  65 ++++----
>   security/landlock/ruleset.h                |  15 +-
>   security/landlock/trace.c                  |  15 ++
>   13 files changed, 365 insertions(+), 113 deletions(-)
>   create mode 100644 include/trace/events/landlock.h
>   create mode 100644 security/landlock/trace.c
> 
> 
> base-commit: a5806cd506af5a7c19bcd596e4708b5c464bfd21

Tested-by: Tingmao Wang <m at maowtm.org>

Here is an example output I got with `trace-cmd record -e landlock`:

landlock-add-ru-776   [001] 75134.554776: landlock_add_rule_fs: [FAILED 
TO PARSE] ruleset=0xffff88811a459200 ref_key=18446612686420679296 
allowed=57343 dev=21 ino=53 pathname=/tmp/test
landlock-add-ru-776   [001] 75134.555336: landlock_check_rule:  [FAILED 
TO PARSE] domain_id=7838764077 access_request=4 ref_type=1 
ref_key=18446612686420679296 layers=ARRAY[ff, df]
I suggest adding some more events which I think shouldn't be too 
difficult to implement and I can see them helping a lot with tracing / 
debugging especially by BPF programs or someone new to landlock:

- landlock_restrict_self: Currently we trace out the ruleset pointer in 
add rule, and the domain ID in check rule.  However there is no way for 
someone just looking at this trace (or a BPF program for landlock) to 
relate which rulesets are applied to which domains. I think a simple 
event we could add that will help with this is, on 
landlock_restrict_self, prints out the ruleset passed in as well as the 
domain ID newly created.  Maybe also num_rules and num_layers on the new 
ruleset since it's trivial to do so, and could be informative to someone 
analyzing a Landlock thing.

- landlock_check_fs: Distinct from landlock_check_rule, this will happen 
once the outcome of the access check is determined (maybe at the end of 
is_access_to_paths_allowed and collect_domain_accesses?). It would 
include the pathname of the target file (only allocated if this event is 
enabled of course), so something like:

   landlock_check_fs: domain_id=7838764077 access_request=4 
pathname=/tmp/test allowed=true
   landlock_check_fs: domain_id=7838764077 access_request=4 
pathname=/tmp/test2 allowed=false

We already produces audit logs for denied requests so it is a little bit 
duplicating that, but I think this trace event shouldn't be too costly 
to include.  It has the benefit that

1. If an access is denied because no rules matched, we don't get any 
landlock_check_rule traces, and so there's no way for someone looking at 
the trace log to find out landlock denied something.

2. Having an event that represents an access check makes it possible for 
BPF programs to find out about all landlock access checks (most 
interestingly denied ones but we could expose the allowed ones too), and 
potentially relate the various `landlock_check_rule` events to an access 
check.

Actually, maybe it's worth having a "landlock_check_fs_enter", emitted 
at the beginning of is_access_to_paths_allowed and 
collect_domain_accesses? This could be useful for performance 
measurements, and also makes it more explicit which landlock_check_rule 
resulted from which access check.  Maybe the pathname and domain_id 
could be printed on the enter event, and the exit event would just have 
the outcome?  (Just an idea, I feel less certain about this. 
"Enter"/"exit" naming taken from sys_enter_*/sys_exit_* but start/end 
also works)