Re: Article: State of Sandboxing in Linux

[Ali Polatel <alip () hexsys org>]

On Sunday, November 24th, 2024 at 11:52, Mickaël Salaün <mic () digikod net> wrote:

> Nice article! I somehow miss this email...

Thank you!

> This is neither a bug nor a feature, but a current limitation
> highlighted in the documentation:
> https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
> This limitation is due to the current path-based LSM hooks (e.g. also
> used by AppArmor and Tomoyo), but we plan to address that:
> https://github.com/landlock-lsm/linux/issues/9

Thank you for taking the time to explain this. It makes more sense now.
Hiding paths is a feature i work on sydbox as well. Our main goal with
this, however, is not really security, rather we want to ensure each and every
package build can only "see" the files it depends on (directly or indirectly).
This is going to effectively prevent automagic dependencies[1] at sandbox level
and bring us one step closer to hermetic builds akin to Bazel.

There are some open questions we have wrt. our implementation which may not be
an issue for Landlock due to its hierarchical nature, however I'll still state
them here as food for thought:

1. What happens if I pass-thru a hidden directory on my way to an allowed directory?
2. How does the dotdot (ie `..`) entry look when i getdents in an allowlisted directory
which is right beneath a denylisted one?

AFAICT, under Landlock you cannot allow a directory beneath an already denied
directory tree, so these are possibly non-issues on your side.

> Sandboxer tools using Landlock may mislead users to think this kind of
> access may be denied but if we take a look at the Landlock filesystem
> access rights, none of them control path walk. It should be noted that
> Landlock still provides the required access rights to protect users'
> data. Only access to metadata cannot be controlled yet.

> Thanks to incremental development, Landlock is gaining more and more
> features with new kernel versions:
> https://docs.kernel.org/userspace-api/landlock.html#previous-limitations
> You can find more information about Landlock's development in the
> related article:
> https://landlock.io/talks/2024-06-06_landlock-article.pdf

Thanks for sharing. Currently we use Landlock ABI-3 for sydbox. This
is because so far all the new features provided by new ABIs (ioctl,
abstract sockets etc) are already confined by our seccomp-sandbox. That
said, I do want to integrate new landlock abis into sydbox for
defense-in-depth. History shows having multiple layers sufficiently raises
the bar for the attacker. Most recent example is the landlock houdini escape
which does not work under sydbox for 2 reasons: The "easy" reason is keyctl(2)
is denied by default with a startup option to allow it. However, even if its
allowed, because the offending keyctl(2) call happens in the sandbox process,
and the escaping open(2) actually happens in a sydbox emulator thread which
is confined with the same landlock sandbox, privilege escalation is still not
possible. I firmly believe this design will stop many similar attacks in the future.

[1]: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies

Best regards,
Ali Polatel

Attachment: publickey - alip@hexsys.org - 0xC22DA9DE.asc
Description:

Attachment: signature.asc
Description: OpenPGP digital signature