bwrap: Implement ability to switch AppArmor profiles

[pks-t]

Bubblewrap is currently hard to use in combination with AppArmor
profiles. The root cause of this is that it sets the NO_NEW_PRIVS flag
quite early in the process, and if that flag is set then most AppArmor
profile transitions are disallowed (except for unconfined -> confined
and profile stacking). This makes it rather hard to have a central
profile for bwrap acting as a portal with "normal" profiles. While this
could be solved by granting the bwrap profile itself full permissions to
everything on the system and then only use stacked transitions, this
feels overly dangerous especially considering that bwrap is typically
installed setuid.

To fix this issue, this commit instead introduces the ability to
explicitly transition to a specific target AppArmor profile. This allows
us to perform the transition before we set the NO_NEW_PRIVS flag and
thus make them both work together. There are two downsides to this:

- NO_NEW_PRIVS must be set at a much later point in time, namely
  after the sandbox has been constructed and the new profile has
  been changed to. While we could switch to the profile at a much
  earlier point in time, this would require the target profile to
  grant permissions required to construct the sandbox. We cannot use
  AppArmor's "change_onexec" transition either: even if we set the
  transition up while NO_NEW_PRIVS is not yet effective, the profile
  switch on exec is going to be denied anyway.

- In order to allow switching the profile, we need to have a
  writable "/proc". This is required such that we can effect the
  transition via a write to "/proc/self/attr/apparmor/current".

Neither of these downsides should be a problem though: NO_NEW_PRIVS'
main intent is to avoid granting new privileges on execve(2), which it
still does given that execve(2) is the last step. And "/proc" being
writable shouldn't matter much when a pid namespace is in use.

Implement AppArmor profile switching via a new "--apparmor-profile"
switch and document it.

Signed-off-by: Patrick Steinhardt [email protected]

[Maryse47]

While this could be solved by granting the bwrap profile itself full permissions to
everything on the system and then only use stacked transitions, this feels overly dangerous

Do you mean using bwrap within permissive apparmor profile is dangerous and with no profile at all it isn't?

especially considering that bwrap is typically installed setuid.

Typically where? Debian stable has it as setuid but current testing has switched to non-setuid bwrap. Other most popular distro used non-setuid bwrap already.

[pks-t]

On Tue, May 25, 2021 at 07:27:07AM -0700, Maryse47 wrote: > this feels overly dangerous especially considering that bwrap is typically installed setuid. Like where? Debian stable has it as setuid but current testing has switched to non-setuid bwrap. Other most popular distro used non-setuid bwrap already.

Fair enough, that statement may have been overly general and was based on a knowledge gap on my side. I still think it's useful to manually specify an AppArmor profile transition such that one can easily specify the profile under which the contained process should be running in the end.