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

[Simon McVittie]

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/**" is meaningless if my /tmp might not be
the same /tmp as everyone else's.

Regards,
    smcv