Mount private information leakage

[voidastro4]

It would appear that some information is leaking somehow.

The mount command is able to reveal information such as: /dev/mapper/vg_unique_name on /lib type ext4 (ro,nosuid,nodev,relatime)

When using --ro-bind /path/rootfs/lib /lib

Is this a bug or is there some way to hide this information? If so, it should be documented prominently.

Edit: There is also another leak.

ps -f | cat is able to show the full bwrap command which also may contain private information such as paths that were used. Is there a way to hide the bwrap process from the container?

[rusty-snake]

1. Mountinfo can be blocked by not mounting any procfs and installing a seccomp filter that blocks statmount/listmount.
2. Commandline can be hidden by using --args.

[voidastro4]

1. Mountinfo can be blocked by not mounting any procfs and installing a seccomp filter that blocks statmount/listmount.
2. Commandline can be hidden by using --args.

2. Thank you.

Not mounting a procfs renders bwrap not usable for many targets. Is there another way to strip such information?

[smcv]

If the kernel wants to provide information, there is not a lot that bwrap can do to prevent it from doing so.

[smcv]

As documented in https://github.com/containers/bubblewrap/blob/main/README.md#sandbox-security, bubblewrap is a tool for constructing sandbox environments, and is not a complete, ready-made sandbox with a specific security policy. It's up to each user of bubblewrap to decide what their desired security model is, and give it options that will achieve that security model.

If your desired security model is not actually achievable within what the Linux kernel offers, then no combination of bubblewrap options is going to provide it, because we can't do impossible things.

As a general rule, sandboxing is a trade-off: the more privacy, confidentiality and protection against malicious code you want, the more functionality and performance you will have to sacrifice in order to achieve them. The configurations that can be achieved with bubblewrap tend to be at the relatively full functionality, high performance, limited protection end of the scale. If you want stronger protection and are willing to sacrifice functionality and performance to get it, consider using heavier-weight containers (such as Podman, Docker, LXC, Incus) or virtual machines (such as GNOME Boxes, virt-manager or Qubes), which are outside the scope of bubblewrap.

bubblewrap was originally designed for use with Flatpak, which doesn't really have infoleaks as part of its threat model: if a Flatpak app wants to fingerprint your system, there are lots of ways it can do that (and this is a necessary limitation to make it possible to use Flatpak to run pre-existing apps, without having to redesign the app to be less like normal Linux and more like Android).

Not mounting a procfs renders bwrap not usable for many targets

Yes, this is a good example of having to sacrifice functionality to get stronger protection.

[rusty-snake]

Is there another way to strip such information?

Since mountinfo is per process, you can not use subset=pid or equivalents. Maybe you can mess with SELinux, fanotify, seccomp_unotify. However this has to be done outside of bubblewrap, tends to be complex and error prone. Otherwise I leave with

If the kernel wants to provide information

[smcv]

I think the conclusion here is: bubblewrap is doing what it can, and it's up to the user of bubblewrap to piece together a command-line that has their desired security properties. bubblewrap is mechanism, not policy: rather than being a complete, ready-to-use sandbox with its own security model, it's more like a toolbox from which you can construct your own sandbox, subject to the limitations of what the kernel will allow.

For /proc, the only options the kernel really gives us are "/proc is mounted, exposing some information in /proc/*/mountinfo" and "/proc is not mounted, breaking many applications". It's your choice which of those options you consider to be less bad.

For the statmount/listmount syscalls, I think the only thing you can do is to compile a seccomp filter that forbids those syscalls, and install it with --add-seccomp-fd (or the older --seccomp option).

Making the kernel provide new ways to avoid exposing this information is outside the scope of bubblewrap. If your desired security model needs new kernel features, you're welcome to contribute those features to the kernel (and then depending on how they work, it might be appropriate to add options for them to bubblewrap, but first they need to exist).