Supervise mode

[micromaomao]

Hi, this is a tracking issue for a feature which I'm proposing, which will allow landlock to delegate policy decisions to a user-space "supervisor".

There has been some discussion on the mailing list already but following discussion with @l0kod I'm creating an issue here (significant comments should still ideally be posted on the mailing list tho)

v1: https://lore.kernel.org/all/cover.1741047969.git.m@maowtm.org

Note that the design has evolved a bit, and following discussion with Mickaël it seems that #1 (Domain hash table) and mutable domains would be perquisite for this, and this patch would instead use a "supervisor modify domain to allow access then allow the original syscall to be retried" approach. There is some outstanding questions regarding file/dir/link/node creation, namely, how do we grant creation on a one-off basis so that the app can only create names "approved" by the user.

Will add summary of the discussion here later on.

[l0kod]

Here is an update on the latest proposed design. I'm not sure about the naming but that's the idea.

Let's define two kind of rulesets:

• simple/supervisee rulesets (current ruleset type, the only one that can be passed to landlock_restrict_self(2)). They can be delegated to potentially untrusted processes and can leak without issue.
• supervisor rulesets (only used by a supervisor). Leaking them would be a sandbox bypass.

Add a new flag to landlock_create_ruleset(2) to create a supervisor ruleset instead of a simple ruleset.

From a supervisor ruleset FD, we can get a supervisee ruleset FD thanks to a dedicated IOCTL command. Its properties are those defined by the initial landlock_create_ruleset(2)'s attributes.

When landlock_restrict_self(2) is called by the supervisee ruleset, a new domain in created by merging the current/parent domain with the supervisee ruleset (each still identified by their layer), and by tying this last domain's layer (struct landlock_hierarchy) to the supervisor ruleset. This is required to avoid the supervisor to change inherited restrictions.

Once the domain is created, the inherited and supervisee rules are copied to the domain and become immutable. Only the supervisor's rules can be added (and removed).

The supervisor might not be used as-is but transformed to a hash table when updated (like the supervisee ruleset when creating a new domain).

These new flags could be added to landlock_add_rule(2):

• LANDLOCK_ADD_RULE_INTERSECT: can be used to remove access rights to an existing rule (i.e. binary AND with previous access rights). If the intersection is 0, to entirely remove the rule. If no rule exist with the same object, the request should probably return an error.
• LANDLOCK_ADD_RULE_COMMIT_SUPERVISOR: to synchronize the ruleset with the related supervisor hash table tied to domains. This flag will only be accepted for supervisor rulesets.
• LANDLOCK_ADD_RULE_QUIET: to not forward the sandboxed process's request to the supervisor if it matches this rule. This will be useful to limit noise. The same logic could be used to not log denied request matching this rule (with audit). To make it simple, I guess this should apply to the final (union) rule, not only the specific one being requested, except if LANDLOCK_ADD_RULE_INTERSECT is set (i.e. only use one bit for this property instead of one per access right).

Work on this supervisor mode feature can start with standalone patch series:

• Domain hash table #1
• LANDLOCK_ADD_RULE_INTERSECT support.
• LANDLOCK_ADD_RULE_QUIET support (for audit log). We might want to change the name though.

[micromaomao]

Here is an update on the latest proposed design. I'm not sure about the naming but that's the idea.

Are we planning to use this mechanism for both mutable domains and the supervisor feature? In which case maybe we should just call the rulesets "mutable" ("dynamic"?) and "static", rather than "supervisee" and "supervisor"? In that case supervisor feature would be a quite natural extension to mutable domains.

When landlock_restrict_self(2) is called by the supervisee ruleset, a new domain in created by merging the current/parent domain with the supervisee ruleset (each still identified by their layer), and by tying this last domain's layer (struct landlock_hierarchy) to the supervisor ruleset. This is required to avoid the supervisor to change inherited restrictions.

Is the idea that the mutable/supervisor ruleset would effectively "OR" with the static/supervisee ruleset of the corresponding layer?

To make this clear, in this design, when checking an access request, landlock will use the following logic (I will denote supervisee ruleset as "static" rulesets and supervisor rulesets with "dynamic" for now):

layer_mask_t static_layer_mask, dynamic_layer_mask, quiet_layer_mask;
initialize static_layer_mask and dynamic_layer_mask to all 1 (all denies), quiet_layer_mask to 0.

walk dentry parents, collect denials for the static part into static_layer_mask,
and if static part denies access and layer has dynamic part,
collect denials for the dynamic part too into dynamic_layer_mask.
If any quiet rules matches the access, set quiet_layer_mask[layer] to 1.

layer_mask_t merged_mask = static_layer_mask & dynamic_layer_mask;
if (merged_mask == 0)
  return allow; // every layer allowed access, whether it's the static part or
                // dynamic part that allowed it doesn't matter

for_each_set_bit(layer in merged_mask) {
  if (quiet_layer_mask[layer]) {
    return deny;
  }
  if (layer does not have supervisor) {
    audit_denial(layer, ...);
    return deny;
  }
}

// by this point all denied layers are supervised, so ask them
for_each_set_bit(layer in merged_mask) {
  queue supervisor event for supervisor of layer
  wake up that supervisor
  landlock_creds(current->creds)->landlock_waiting_for_supervisors |= BIT(layer);
}
add task work landlock_supervise_wait_work;
return -ERESTARTSYSNOINTR;

void landlock_supervise_wait_work() {
  for_each_set_bit(layer in landlock_creds(current->creds)->landlock_waiting_for_supervisors) {
    int answer = wait_for_supervisor();
    if (answer == deny) {
      audit_denial(layer, ...);
      // somehow sets return code of syscall to -EPERM
      return;
    }
  }
}

Does this seem correct?

LANDLOCK_ADD_RULE_QUIET: to not forward the sandboxed process's request to the supervisor if it matches this rule. This will be useful to limit noise. The same logic could be used to not log denied request matching this rule (with audit). To make it simple, I guess this should apply to the final (union) rule, not only the specific one being requested, except if LANDLOCK_ADD_RULE_INTERSECT is set (i.e. only use one bit for this property instead of one per access right).

Does this inherit downward the directory tree? (i.e. if there is such a quiet rule at /a, access to /a/b are also treated as quiet)

Also, if a supervisor wants to suppress requests/audit for a fs hierarchy without allowing any access at all, can it pass in a rule with no access bits?

[micromaomao]

(actually I forgot that the layer masks are per-access-bit, so this would in fact be a bit more complex)

[l0kod]

Are we planning to use this mechanism for both mutable domains and the supervisor feature? In which case maybe we should just call the rulesets "mutable" ("dynamic"?) and "static", rather than "supervisee" and "supervisor"?

I don't really see a use case with a mutable domain without a supervisor (i.e. domain mutability + notification), but this is a way to split work.

In that case supervisor feature would be a quite natural extension to mutable domains.

Yes.

The idea is that the supervisee FD is in fact a ruleset FD as used today and it provides exactly the same features and is seen as a [landlock-ruleset] FD. I guess that was misleading. With this approach, the API is more difficult to be misused, and it simply expresses the hierarchy of the supervisor wrt the supervisee/ruleset.

Is the idea that the mutable/supervisor ruleset would effectively "OR" with the static/supervisee ruleset of the corresponding layer?

Yes, extending the mutable/supervisor ruleset should have the same effect as populating the normal/supervisee ruleset (before it is applied). A supervisor would only be able to change its ruleset, which means to allow new things or remove its rules, but not remove the rules put in place by the supervisee before sandboxing itself (keeping in mind that in this model the supervisee is initially trusted).

[l0kod]

landlock_creds(current->creds)->landlock_waiting_for_supervisors |= BIT(layer);

Credentials may change per thread/process in the same domain, so these bits should probably be tied to the domain itself.

Does this seem correct?

Yes, it looks good overall.

LANDLOCK_ADD_RULE_QUIET: to not forward the sandboxed process's request to the supervisor if it matches this rule. This will be useful to limit noise. The same logic could be used to not log denied request matching this rule (with audit). To make it simple, I guess this should apply to the final (union) rule, not only the specific one being requested, except if LANDLOCK_ADD_RULE_INTERSECT is set (i.e. only use one bit for this property instead of one per access right).

Does this inherit downward the directory tree? (i.e. if there is such a quiet rule at /a, access to /a/b are also treated as quiet)

It should not require Landlock to walk back to the root for each access request. A quiet flag only applies to its rule (i.e. all access rights tied to a specific kernel object).

In you example, if Landlock needs to walk to /a because the requested access is not granted by /a/b, then for the denial to be quiet, each evaluated rule (e.g. /a and /a/b) needs to have the quiet flag.

Also, if a supervisor wants to suppress requests/audit for a fs hierarchy without allowing any access at all, can it pass in a rule with no access bits?

Wouldn't it be simpler for the supervisor to just not handle such access right?

We have LANDLOCK_RESTRICT_SELF_LOG_* flags but that may not be flexible enough. We could also have a "quiet" bitmask in struct landlock_ruleset_attr to mute specific access rights. I'm not sure if it's worth it.

[micromaomao]

Does this inherit downward the directory tree? (i.e. if there is such a quiet rule at /a, access to /a/b are also treated as quiet)

It should not require Landlock to walk back to the root for each access request. A quiet flag only applies to its rule (i.e. all access rights tied to a specific kernel object).

If Landlock denies an access, it will always need to walk to the root to make sure there isn't an allow rule anywhere from root to target right? i.e. walk can't terminate early unless the access is allowed, and if it is allowed then whether quiet or not doesn't matter.

In you example, if Landlock needs to walk to /a because the requested access is not granted by /a/b, then for the denial to be quiet, each evaluated rule (e.g. /a and /a/b) needs to have the quiet flag.

This semantic was not how I initially understood it - I thought of "quiet" as basically another "access right". However, if all evaluated rules along a path needs to have the quiet rule for an access to be quiet, then for a ruleset like

/: r-x
/dev: quiet

if the intention is to make any access denials under /dev quiet, then one would be forced to also have quiet on / too, but then any access denials under other directories would also be quiet since there are no other rules.

I think it would make sense to require all layers to agree on the "quietness" (otherwise still audit denials), but not all rules. (unless I'm misunderstanding something?)

Also, if a supervisor wants to suppress requests/audit for a fs hierarchy without allowing any access at all, can it pass in a rule with no access bits?

Wouldn't it be simpler for the supervisor to just not handle such access right?

What do you mean by "not handle"? If it doesn't create any rules for the directories which it wants to be quieted, how would landlock know what denials to suppress and what to log?