Re: [apparmor] What to do about bubblewrap started from apps confined with AppArmor?
On Wed, 20 Sep 2017 at 13:36:41 -0700, Seth Arnold wrote:
> On Wed, Sep 20, 2017 at 01:15:20PM +0200, intrigeri wrote:
> > 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?
bwrap is an adverb command, like env, sudo or aa-exec. You cannot ever
enumerate everything that it executes, because it executes whatever
it's told to; so /etc/apparmor.d/usr.bin.bwrap would make no sense.
Enumerating everything that is executed through bwrap *by Totem* is a
more solvable problem, so a bwrap child profile within a larger profile
does make sense. Something like this (please excuse any syntax failures,
my AppArmor-profile-writing is rusty):
profile /usr/bin/totem {
...
/usr/bin/bwrap Cx -> bwrap,
profile bwrap {
capability sys_admin,
...
/newroot/{usr/,}bin/true Cx -> true,
/newroot/usr/bin/totem-video-thumbnailer Cx -> totem-video-thumbnailer,
profile true {
/newroot/{usr/,}bin/true rm,
/newroot/{usr/,}lib*@{multiarch}/** rm,
... anything else /bin/true might need ...
}
profile totem-video-thumbnailer {
/newroot/usr/bin/totem-video-thumbnailer rm,
/newroot/{usr/,}lib*@{multiarch}/** rm,
/newroot/tmp/** rw,
... GStreamer stuff here ...
}
}
}
(Executing /bin/true via bwrap seems to be a reasonably common pattern
to detect whether we can even use it and do a graceful fallback if we
can't, so I'd suggest always preemptively allowing that.)
However, I'm not sure whether that actually works, because bwrap sets
PR_SET_NO_NEW_PRIVS before executing its child process; and because
an AppArmor profile transition can add as well as remove permissions
(there is no total ordering), an AppArmor profile transition (for
example, from /usr/bin/totem//bwrap to
/usr/bin/totem//totem-video-thumbnailer) is forbidden under no_new_privs
rules. The only exception that I'm aware of is the transition from
unconfined to any confined profile, which is a reduction in privilege,
so is allowed even under no_new_privs.
The reason bwrap must set PR_SET_NO_NEW_PRIVS is to prevent attacks that
subvert setuid processes' expectations that particular parts of the
filesystem are root-controlled and trustworthy, for example mounting
a crafted ~/passwd over /etc/passwd and running su.
> 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
The question here is, do you trust AppArmor more than you trust
the combination of PR_SET_NO_NEW_PRIVS and a mount namespace in which
only a whitelist of desired paths exist?
The vulnerabilities that have been found in bwrap so far are:
* CVE-2017-5226: The confined process could stuff input into its
controlling terminal with TIOCSTI, unless the invoking app sets up
a seccomp filter that forbids this (both Flatpak and libgnome-desktop
do that), or creates a new pty and forwards everything between that
and the real terminal (like modern su and sudo versions do), or
wraps bwrap in setsid(1), or runs bwrap with the --new-session option
* CVE-2016-8659: Processes outside the sandbox could ptrace bwrap after
it has dropped privileges, and instruct it to instruct a
still-privileged bwrap helper process to do privileged things inside
the sandbox; one of those privileged things (sethostname()) can affect
the host system, and the rest are an unintended level of exposure of
kernel attack surface
Neither of those actually involves the confined process exercising
bwrap's privileges or accessing files with access rights inherited from
bwrap. In CVE-2017-5226, the confined process inherited a fd to its
controlling terminal and was presumably meant to be using it for output
(that's a write), but used TIOCSTI (also mediated as a write, I suspect)
to remote-control the shell with which it was sharing the controlling
terminal. I don't think AppArmor would help here.
CVE-2016-8659 can't be exploited by the confined process as far as I know,
only by something on the outside; and, again, the vulnerability involves
a less-privileged process remote-controlling a more-privileged process
(actually two levels of that, in this case). AppArmor could prevent the
attacker from ptracing the unprivileged bwrap process, but it could not
prevent the unprivileged bwrap process from sending instructions to the
privileged bwrap process, because that's how the privilege separation is
meant to work under normal circumstances.
More generally, AppArmor's path-based model of objects just doesn't seem
a particularly great fit for technologies like bwrap (and other
containers) that use mount namespaces to alter what paths mean.
"I'm allowed to write to /tmp/**"
Re: [apparmor] What to do about bubblewrap started from apps confined with AppArmor?
On Wed, Sep 20, 2017 at 01:15:20PM +0200, intrigeri wrote: > 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 signature.asc Description: PGP signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] What to do about bubblewrap started from apps confined with AppArmor?
On 09/20/2017 04:15 AM, intrigeri wrote:
> 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
>
> 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?
>
This doesn't look right and I will have to spend some time looking into
it, what kernel version are you using? 4.12?
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] What to do about bubblewrap started from apps confined with AppArmor?
On Wed, 20 Sep 2017 at 16:53:19 +0200, intrigeri wrote: > 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 -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] What to do about bubblewrap started from apps confined with AppArmor?
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, -- intrigeri -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] What to do about bubblewrap started from apps confined with AppArmor?
On Wed, 20 Sep 2017 at 13:15:20 +0200, intrigeri wrote: > 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. > 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 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 -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] What to do about bubblewrap started from apps confined with AppArmor?
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
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,
--
intrigeri
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
