Blacklist-based sandboxing

[cd-work]

This might not be the perfect place for this question, but since you're involved in the Kernel development too I thought I'd use this opportunity to reach out.

As far as I can tell Landlock only allows what I'd refer to as "Whitelist-based sandboxing", where everything is denied by default and you can add exceptions to allow things.

However it does not seem like it is possible to deny access to one specific resource, while allowing access to everything else, is that correct?

To elaborate a little bit, my usecase would be denying access to data that is known to be vulnerable, while trying to not hinder the user too much. If you wanted to deny read access to ~/.ssh for example, it seems like currently you'd have to walk the entire home directory and add exceptions for every directory. Then users still wouldn't be able to read files immediately in the home directory or directories added after the sandbox creation.

Did I miss something with how Landlock works at the moment, or does this sound correct? I tried removing access to specific directories by adding a rule with BitFlags::EMPTY but that gives me an error.

[bjorn3]

Something like this would also be useful to allow denying access to /home except for the single directory it needs to access like a singld code project in case of a build system while still allowing read-only access to all system files to allow spawning new processes like a compiler that access those system files.

[l0kod]

I tried removing access to specific directories by adding a rule with BitFlags::EMPTY but that gives me an error.

This is indeed an error because such rule would be useless. If there is an error, the developer should be aware and handle this case.

Did I miss something with how Landlock works at the moment, or does this sound correct?

It is currently not possible to follow this deny-listing approach. This would be useful for some use cases, but I prefer to encourage people to define a set of allowed accesses rather than deny accesses to follow a good security practice. However, this is a limitation and it may still be handy to deny access to filesystems on which the topology is imposed by the system (e.g. deny some files in /proc or /sys) or to have more sandboxing thanks to more generic (and tested) rules. To be able to securely only deny paths, Landlock would need to automatically create extra rules (e.g. to avoid sandbox escape through file renaming), see @thejh's example:

e.g. if someone grants full access to $HOME, but excludes $HOME/.ssh,
an attacker would still be able to rename $HOME/.ssh to $HOME/old_ssh,
and then if the program is later restarted and creates the ruleset
from scratch again, the old SSH folder will be accessible.

I'd be happy to help develop such feature for Landlock.