Mutable domain

[micromaomao]

Hi,

Since mutable domains would be a prerequisite of supervise mode (#44), I would like to start working on that.

In previous discussion with @l0kod he was worried about the performance implication of this (which will have to be implemented by walking multiple rbtrees - so that updates to mutable domains created in earlier layers are reflected in the child layers). In benchmarking the existing landlock and seeing how it scale with number of rules (landlock-lsm/landlock-test-tools#17), I think actually this might not be that significant. I can knock out a prototype that will maybe just treat every layer as mutable and test its performance to be sure.

https://github.com/landlock-lsm/landlockconfig seems like it would be useful here - a first step could be to have the sandboxer example in there dynamically reload the json config on change, build a new ruleset, and do a landlock_domain_swap (uapi tbd)?

(we also talked about how there could be a "static" part and a "dynamic" part, and the dynamic part would only be searched if the static part denies access, but now I wonder if this is overkill...)

[micromaomao]

(note: earlier I accidentally posted the issue before finishing writing it)

(@l0kod can you assign this to me?)

[l0kod]

I can knock out a prototype that will maybe just treat every layer as mutable and test its performance to be sure.

I guess you want to keep domains as rulesets for this benchmark and avoid copying rules but referencing the parent layer instead?

(we also talked about how there could be a "static" part and a "dynamic" part, and the dynamic part would only be searched if the static part denies access, but now I wonder if this is overkill...)

Currently domain contains rules from all layers. The issue with merging the static and dynamic part is that we would have to follow every copies of a domain (i.e. nested domains) to update their rules, which doesn't scale. I summarize that in #44 (comment).

[micromaomao]

Currently domain contains rules from all layers. The issue with merging the static and dynamic part is that we would have to follow every copies of a domain (i.e. nested domains) to update their rules, which doesn't scale. I summarize that in #44 (comment).

I was more thinking that for dynamic layers we will just not have any new static rules (and thus, nothing to propagate - all access checks (that aren't denied by any prior non-dynamic layers) will have to check dynamic layers). However, on second thought, because we want to have separate supervisor and supervisee fds (#44 (comment)) to prevent accidentally allowing the sandboxed process to change its own landlock rules / allow its own access, we might as well have two rulesets, and the one that gets exposed to the child can represent the "static" part.