Add a --not-a-security-boundary option

[smcv]

trafficstars

Depending on the options that it's given, the new namespaces created by bubblewrap might be:

• a sandboxed environment, with a security boundary between the real system and the sandbox (for example Flatpak uses it this way when running the actual app)
• a non-sandboxed environment, with differences between the real system and the sandbox, but no meaningful security boundary (for example Flatpak uses it this way when running xdg-dbus-proxy, and the Steam Runtime uses it this way when running Steam games)

If there is meant to be a security boundary, lots of features of bubblewrap need to "fail closed". For example, if we are told to provide a filesystem, and we fail to remount it ro or nosuid, then our only choice is to refuse to run the wrapped program (fail closed), because if we carried on anyway (fail open) then we would not be providing the intended security properties.

However, if there is not meant to be a security boundary, for a lot of failures we can consider ignoring the failure (possibly with a warning) and carrying on anyway.

At the moment, bubblewrap has no way to tell which of these security models the user of bubblewrap is looking for, so we have to make the conservative/pessimistic assumption that they do want a security boundary, and fail closed.

However, if we added a --not-a-security-boundary option, we could use it to make bubblewrap more robust in the cases where something unexpected goes wrong, such as #650. Pseudocode:

if (a thing fails)
  {
    if (not_a_security_boundary)
      warn ("the thing failed (%s), continuing without doing the thing", strerror (errno));
    else
      die_with_error ("the thing failed");
  }

[smcv]

cc @refi64

[xplshn]

This would be a desired feature for a large part of the AppImages community, AppBundle community, NixAppImage project, and others. It'd be great to have this :)

[xplshn]

@smvc meanwhile, could a list of bwrap flags necessary to make it work like a simple chroot that doesn't sandbox anything be provided? I've been battling with bwrap for various hours now, I can't figure out how to make it disable all sandboxing capabilities, including but not limited to seccomp, etc.

It'd be great if at least a list of these were provided

See: https://github.com/linuxserver/docker-webtop/issues/192#issuecomment-1858809373

[rusty-snake]

(Off topic)

I can't figure out how to make it disable all sandboxing capabilities, including but not limited to seccomp, etc.

Very simple: do not pass any --seccomp or --add-seccomp-fd argument. No seccomp filter will be installed.

User and mount namespace will always be unshared.

[smcv]

could a list of bwrap flags necessary to make it work like a simple chroot that doesn't sandbox anything be provided?

I think what you are asking for is bwrap --dev-bind /chroot / -- COMMAND, which is the closest the kernel will allow us to get to chroot /chroot -- COMMAND without using root-equivalent privileges or a setuid executable.

But I don't think that is actually what you want, because your screenshot of some text seems to be sharing various directories with the host system, so it seems that your use-case is not a simple chroot, but instead a somewhat more complicated container.

In general bwrap provides mechanism but not policy, and it is up to you to design a container/sandbox that meets your needs (which, as a prerequisite, requires understanding your needs). I'm sorry, but the bubblewrap maintainers have too many other responsibilities to be able to provide detailed tuition about this or other aspects of how to use bubblewrap.

All of this is off-topic for a feature request about adding a new option.

[xplshn]

bwrap --dev-bind /chroot / -- COMMAN

Thanks! I'll be using that