Fwd: VirtualBox/setuid binaries

[Alexander Larsson]

On Thu, Nov 15, 2018 at 1:12 PM Michael Thayer
<michael.thayer at oracle.com> wrote:
>
> 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.

Flatpak is fundamentally based on the kernel support for unprivileged
user namespaces. This is the way we can launch a "container" sandbox
without ever needing to be root. (We alternatively also support doing
the same thing via a setuid bwrap helper, but that is immaterial for
this dicussion, so lets ignore that for now). We use the
PR_SET_NO_NEW_PRIVS prctl to guarantee this, and unless we do that,
the namespace operations will fail.

Now, why does the kernel require this? It is because of the way the
unix operating system works, with a policy-free kernel, and a policy
setting userspace. The userspace part depends on privilege raising
operations like setuid. For example, take sudo. It is setuid, so all
users running it becomes root, but before running any untrusted code
it verifies that the calling user is allowed to do this by reading the
system config, in this case /etc/sudoers. This relies on the hardcoded
path "/etc/sudoers" in the setuid binary being trusted. However, if
you're allowed to do arbitrary filesystem namespace modifications such
a path cannot be trusted.

In other words, the second you allow a flatpak sandbox to run a setuid
program you can use it to exploit the host system by shipping its own
/etc/sudoers and spawning the host sudo. So, just enabling setuid is
not going to fly.

Maybe there is some workaround though. What exactly is it you need to
be root permissions to do?


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com