Simon McVittie

> We could run bwrap as root and try to run the daemon as a different user This means you are trusting bwrap, even if it is not setuid on...

> Does bubblewrap always have to create a new user namespace? Yes, that's how it gets the ability to do everything else it does.

> Wouldn't setuid bubblewrap be safer than bubblewrap with unprivileged user namespace? See . It's a security trade-off, depending on which threats you consider to be more severe, and which...

I *think* the way Flatpak uses this is that every user of a runtime or app takes a read lock, and Flatpak itself takes a write lock when it wants...

I think I'm going to apply #227 in Debian experimental, since having the tests pass reliably is a really nice property to have (even if we're not 100% convinced they're...

> It can theoretically enhance sandbox security as bind-mounting protected paths inside accessible paths won't expose anything to the sandbox It can also make sandbox security worse, by having files...

I don't think we can allow this in situations where bwrap is privileged (setuid root), because it would give users the ability to do something that the sysadmin thought they...

@RyuzakiKK, perhaps you could do some not-a-maintainer review here?

It's true to say that for programs like web browsers, which aim to enforce a security boundary within themselves (between the UI and the web content), a program running inside...

bubblewrap can be affected if the command inside the container runs attacker-supplied code as real uid 0 (i.e. uid 0 outside the container, not just uid 0 in a different...