Before enforcing a sandbox on a fleet with potential different configurations and states, it would be useful to know whether a restriction would have an effect on legitimate use cases. By being able to have a permissive/not-enforcing mode and thanks to #3, telemetry can inform us of all access requests that would have been denied. We can then improve the sandbox configuration and get guarantees that it will not break current workstream.
This should be configurable with a new LANDLOCK_RESTRICT_SELF_PERMISSIVE flag passed to landlock_restrict_self(). Of course, this flag must only apply to the new domain layer, the inherited restrictions and the future nested restrictions will still be enforced.
Related to landlock-lsm/rust-landlock#36, but this would be implemented kernel-side. Both implementation are valuables and complementary for different use cases:
user space libraries: debugging, testing and telemetry for (unprivileged) app developers;
kernel audit: debugging, testing and telemetry for system administrators.
Before enforcing a sandbox on a fleet with potential different configurations and states, it would be useful to know whether a restriction would have an effect on legitimate use cases. By being able to have a permissive/not-enforcing mode and thanks to #3, telemetry can inform us of all access requests that would have been denied. We can then improve the sandbox configuration and get guarantees that it will not break current workstream.
This should be configurable with a new
LANDLOCK_RESTRICT_SELF_PERMISSIVE
flag passed tolandlock_restrict_self()
. Of course, this flag must only apply to the new domain layer, the inherited restrictions and the future nested restrictions will still be enforced.