I propose adding Landlock support to Bubblewrap

[ChrysoliteAzalea]

trafficstars

Hello everyone!

I propose adding Landlock support to Bubblewrap. Landlock is a Linux security module officially introduced in Linux 5.13 kernel version that allows unprivileged processes to impose filesystem self-restrictions. It can be used in Bubblewrap in order to prevent sandbox escape.

I've created an "experimental" branch in a forked repository with experimental patches adding Landlock support. If Landlock self-restriction is enabled, experimental patched version of Bubblewrap will create and apply a ruleset which only allows access to mounted resources, preventing container escape.

This experimental patch hasn't been fully tested, and may cause bugs in some cases (needs further testing before merging), which is why the experimental branch allows edits by those who have write access to this repository. Moreover, this patch relies on using shared libraries that I use for experimenting with Landlock, which have to be compiled before compiling the experimental branch, which is why I had problems with Meson build system (had to use Autoconf instead).

[Maryse47]

If Landlock self-restriction is enabled, experimental patched version of Bubblewrap will create and apply a ruleset which only allows access to mounted resources, preventing container escape.

Could you describe how it compares to non-landlock Bubblewrap? Can you escape its container?

[ChrysoliteAzalea]

If Landlock self-restriction is enabled, experimental patched version of Bubblewrap will create and apply a ruleset which only allows access to mounted resources, preventing container escape.

Could you describe how it compares to non-landlock Bubblewrap? Can you escape its container?

The difference is, that with my patch, if Landlock protection is enabled, the Bubblewrap process creates ruleset and adds all mounted directories (binds, tmpfs, proc, dev) to it, and all access to resources not included would be blocked by Landlock (during my tests, it blocked the ls / command).

Currently, I haven't found any way to escape the container. However, I think that additional hardening (such as seccomp, Landlock, SELinux, AppArmor) is beneficial for the project as it can help mitigate any possible vulnerabilities should they happen (for example, I use additional AppArmor restriction for Flatpak apps using profile stacking feature).

[ChrysoliteAzalea]

Force-pushed the experimental branch in order to combine and sign commits. No changes to the code itself have been made.

[ChrysoliteAzalea]

I've tested this a bit, and it seems to be working correctly for me. Seems to be ready for review. What has to be done:

• Adding the Landlock syscall wrappers and ruleset helper function to the Bubblewrap code (currently, it's done through shared libraries that are compiled separately)
• Adding support for Meson build system (this patch has not been tested with it)
• Removing the experimental patch warning

[smcv]

all access to resources not included would be blocked by Landlock (during my tests, it blocked the ls / command)

That's an incompatible change. The initial contents of bwrap's filesystem namespace (before you specify any --bind, --dev and so on) is a tmpfs, and the intended semantics are that if you have not done a --bind $some_dir / or similar, then the child process is allowed to access that tmpfs directory (and in particular, it can list the top-level directories, which will typically include /dev, /usr and so on, bind-mounted in from elsewhere). Why would that ever not be desirable?

What the sandboxed process is not allowed to access is the filesystem outside the directory that starts as /newroot - but we enforce that by using pivot_root() to turn /newroot into the root filesystem, and unmounting the old root. That means there is no path that the sandboxed process can use to refer to a file it is not allowed to access: they simply do not exist in its view of the filesystem namespace.

If there are any filesystem sandbox escapes remaining after doing that, then they would be around kernel subtleties like the interpretation of "magic symlinks" in /proc. My understanding is that those would generally be treated as kernel security vulnerabilities, and fixed like any other serious kernel bug.