[apparmor] What to do about bubblewrap started from apps confined with AppArmor?

[intrigeri]

Hi,

on current Debian sid, Totem tries to use bubblewrap (/usr/bin/bwrap).
I've not investigated why yet but I suspect it's part of the GNOME
project's much welcome effort to sandbox dangerous things
like thumbnailers.

bubblewrap sets up Linux namespaces and other stuff that makes it
essentially need full admin access, which is kinda by design for this
kind of sandboxing wrappers (not sure if userns would change anything
to that, anyway that's off-topic right now).

To give you a better idea,here's a named profile suitable for:

/usr/bin/bwrap Cx -> bwrap,

… that's enough to get rid of all bwrap-related AppArmor errors in my
logs when using Totem:

profile bwrap flags=(attach_disconnected) {
#include <abstractions/base>

capability net_admin,
capability setgid,
capability setpcap,
capability setuid,
capability sys_admin,
capability sys_chroot,

@{PROC}/@{pid}/mountinfo r,
@{PROC}/@{pid}/fd/ r,
owner @{PROC}/@{pid}/setgroups rw,
owner @{PROC}/@{pid}/{gid,uid}_map rw,
@{PROC}/sys/kernel/overflow{gid,uid} r,

/run/user/[0-9]*/.bubblewrap/{old,new}root/ rw,
/run/user/[0-9]*/.bubblewrap/{old,new}root/usr/ rw,

/{old,new}root/** rw,

/usr/bin/bwrap mr,
}

At this point I wonder if it's worth our time to write and maintain
a profile for /usr/bin/bwrap. My current take of it is: probably not.

I'll send a merge request later today that allows Totem to run bwrap
in a fully unconfined manner; this should be good enough at least on
the short term, and I think only Debian ships this profile so far so
perhaps most list subscribers don't care much. But I bet this
situation will occur again in more commonly used profiles, so let's
make up our mind about it now :)

Thoughts?

Cheers,

[Simon McVittie]

Post by intrigeri
bubblewrap sets up Linux namespaces and other stuff that makes it
essentially need full admin access, which is kinda by design for this
kind of sandboxing wrappers (not sure if userns would change anything
to that, anyway that's off-topic right now).

Unprivileged userns (as seen on recent Ubuntu, and on Debian if you adjust
/proc/sys/kernel/unprivileged_userns_clone) avoids bwrap needing to be
setuid root in the init namespace (before it creates new namespaces).
It still needs to exercise capabilities in its newly-created namespace
either way.

Post by intrigeri
/usr/bin/bwrap Cx -> bwrap,
… that's enough to get rid of all bwrap-related AppArmor errors in my
logs when using Totem

I'm surprised this works. bwrap is an "adverb" like chroot/sudo/env, so
I would expect it to want to execute the wrapped thumbnailer?

S

[intrigeri]

Post by Simon McVittie
I'm surprised this works. bwrap is an "adverb" like chroot/sudo/env, so
I would expect it to want to execute the wrapped thumbnailer?

Same here! It would be awesome if someone investigated why/how exactly
Totem now uses bwrap.

Cheers,

[Simon McVittie]

Post by intrigeri

Post by Simon McVittie
I'm surprised this works. bwrap is an "adverb" like chroot/sudo/env, so
I would expect it to want to execute the wrapped thumbnailer?

Same here! It would be awesome if someone investigated why/how exactly
Totem now uses bwrap.

I don't see any mentions of bwrap in totem's source code, so presumably
it's via gnome-desktop3, which now wraps thumbnailers with bwrap
(libgnome-desktop/gnome-desktop-thumbnail-script.c). That would mean it's
executing some thumbnailer listed in the Exec line of one of the files
matching /usr/share/thumbnailers/*.thumbnailer, most likely
totem-video-thumbnailer.

So I'm surprised it could work without the bwrap child profile
having "/usr/bin/totem-video-thumbnailer Pix" or something (and perhaps
other thumbnailers but Totem's own is the main one).

smcv

[John Johansen]

Post by intrigeri
Hi,
on current Debian sid, Totem tries to use bubblewrap (/usr/bin/bwrap).
I've not investigated why yet but I suspect it's part of the GNOME
project's much welcome effort to sandbox dangerous things
like thumbnailers.
bubblewrap sets up Linux namespaces and other stuff that makes it
essentially need full admin access, which is kinda by design for this
kind of sandboxing wrappers (not sure if userns would change anything
to that, anyway that's off-topic right now).
/usr/bin/bwrap Cx -> bwrap,
… that's enough to get rid of all bwrap-related AppArmor errors in my
profile bwrap flags=(attach_disconnected) {
#include <abstractions/base>
capability net_admin,
capability setgid,
capability setpcap,
capability setuid,
capability sys_admin,
capability sys_chroot,
@{PROC}/@{pid}/mountinfo r,
@{PROC}/@{pid}/fd/ r,
@{PROC}/sys/kernel/overflow{gid,uid} r,
/run/user/[0-9]*/.bubblewrap/{old,new}root/ rw,
/run/user/[0-9]*/.bubblewrap/{old,new}root/usr/ rw,
/{old,new}root/** rw,
/usr/bin/bwrap mr,
}
At this point I wonder if it's worth our time to write and maintain
a profile for /usr/bin/bwrap. My current take of it is: probably not.
I'll send a merge request later today that allows Totem to run bwrap
in a fully unconfined manner; this should be good enough at least on
the short term, and I think only Debian ships this profile so far so
perhaps most list subscribers don't care much. But I bet this
situation will occur again in more commonly used profiles, so let's
make up our mind about it now :)
Thoughts?

This doesn't look right and I will have to spend some time looking into
it, what kernel version are you using? 4.12?

[Seth Arnold]

Post by intrigeri
At this point I wonder if it's worth our time to write and maintain
a profile for /usr/bin/bwrap. My current take of it is: probably not.

I think it is; first, this does raise the question of why is whatever it
is that it executes not listed in this profile? Getting to the bottom of
that is already a good start. :)

Once that's sorted out, I think it'll be a good to have a list of things
that might possibly have access to all the above privileges in the event
bugs are found in bwrap, and confine those things according to the
privileges they may actually need.

Thanks

[Simon McVittie]

This post might be inappropriate. Click to display it.