VirtualBox/setuid binaries

[Robert McQueen]

Hi Michael,

Firstly - very cool to hear from you and that you are evaluating
Flatpak as a way to distribute VirtualBox. Thanks for reaching out to
us! Inside Endless (a very early adopter of ostree and Flatpak) we've
used VirtualBox extensively for development - although recently due to
it becoming available as a Flatpak we've been using GNOME Boxes based
on KVM.

(Tangentially, I'd be interested to know whether there is "enough"
VirtualBox headed upstream such that the kernel modules wouldn't be
necessary in every case. The Endless host ostrees doesn't have gcc, or
kernel headers, and we have secure boot enabled such that you wouldn't
be able to load a self-compiled kernel module without digging in
mokmanager etc etc. Or is the upstream VirtualBox stuff just about
guest drivers?)

I think it's technically pretty hard for Flatpak to allow setuid
binaries in "normal" operation. We have a user namespace which means
that UID 0 inside is actually the user who launched the Flatpak
outside, so setuid is "squashed" at runtime. Additionally, because of
the general goal that the sandboxing permits safe
installation/execution of "less trusted" binaries, then in order to
prevent any escalation to root (or any other UIDs) with executable
files downloaded as part of a Flatpak, any setuid bits stored in the
ostree are stripped.

That said, Endless OS does something pretty nasty to make a Google
Chrome (which has a setuid sandbox helper) "flatpak", so here are two
tricks you can potentially combine to make something that works:

 - There is an "apply_extra" script which is run locally on the system
after the third party files have been downloaded for an "extra data"
Flatpak where additional files are fetched directly by the client,
rather than all being included inside the Flatpak (for software where
the Flatpak publisher does not have redistribution rights). This is the
closest Flatpak ever gets to a "maintainer script" in that it is run on
the Flatpak app after it has been deployed, and /app/extra is made
writable in this sandbox. If you create or make files setuid in this
script, they will be setuid on the real filesystem.

 - You can, with --talk=org.freedesktop.Flatpak, use the
Development.HostCommand interface to run stuff on the host outside of
the sandbox. See https://github.com/flatpak/flatpak/blob/master/data/or
g.freedesktop.Flatpak.xml#L39 or https://github.com/flatpak/flatpak-xdg
-utils/blob/master/src/flatpak-spawn.c.

By combining these, you could download/create/copy some
helpers/binaries in /app/extra and make them setuid, and have a wrapper
which located the real system path of the setuid thing, and ran it
using HostCommand. If you want to access the kernel, system headers,
etc it's likely that running directly on the host will work better than
being inside the sandbox anyway.

An example is in https://github.com/flathub/flathub/pull/566. Needless
to say, as with that PR, you might not get a warm reception from the
Flathub reviewers, but if you hosted your own ostree repository then
you could publish this type of thing. :)

Cheers,
Rob

On Thu, 2018-11-15 at 11:26 +0100, Michael Thayer wrote:
> Hello,
> 
> I have been following Flatpak for some time, given that we
> (VirtualBox)
> maintain about twenty different builds for different Linux
> distributions.  Obviously Flatpak could potentially solve quite a big
> problem for us, but there is a big catch: the main binaries in
> VirtualBox run setuid root, and that is not something which is going
> to
> change in the near future.  So the question: could you conceive
> adding
> an option to allow setuid root in a Flatpak?  Clearly this is the
> same
> as saying that for that Flatpak there is no security sandboxing, so
> the
> user should be sure that they trust it.  Which with VirtualBox there
> is
> simply no way round, since we include kernel code.
> 
> I have also considered the possibility of providing a forked copy of
> Flatpak in our RPMs and Debs which would re-use your runtimes, but
> although that would probably let us reduce the number we build
> significantly it would be horrible.  And I know that if you did add
> this
> option you would be getting certain people shouting that "Flatpak is
> not
> secure because setuid binaries are setuid", or something on those
> lines.
>  And I also realise that there are probably not that many other
> desktop
> applications which need setuid; but I expect that there are still a
> few
> more.
> 
> Anyway, interested to hear what you have to say.
> Thanks.
> 
> Regards
> Michael
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak