VirtualBox/setuid binaries

[Simon McVittie]

On Thu, 15 Nov 2018 at 15:32:14 +0100, Michael Thayer wrote:
> The main reason that we provide
> our own hypervisor in a kernel module.

Presumably that needs to come from the host system rather than from a
Flatpak?

If so, you could potentially have part of VirtualBox exist outside the
container/sandbox (the part that communicates with the kernel, etc.)
and let the part of VirtualBox inside the container/sandbox interact
with it (possibly communicating via D-Bus or AF_UNIX). That would mean
only a small part of VirtualBox needs to be highly privileged.

> As an added security layer we only let root processes open
> the hypervisor device, rather than giving a group access to it.  Our
> main virtual machine process starts setuid root, opens the device and
> possibly (would have to check) does a couple of other things like
> opening a raw socket for ICMP, then drops privileges.

What added security does this provide for your users? If your main virtual
machine process starts up as root, drops privileges, and accepts arbitrary
configuration/UI actions from ordinary users, does that prevent ordinary
users from manipulating the open hypervisor device in whatever dangerous
way they wanted to?

Similarly, if the main VM process opens raw sockets for ICMP, and then
is controlled by ordinary users after it has dropped privileges, are
ordinary users prevented from abusing the capability[1] represented by
those raw socket fds?

    smcv

[1] in the sense of https://en.wikipedia.org/wiki/Capability-based_security,
    not to be confused with POSIX draft 1003.1e (CAP_SYS_ADMIN etc.) which
    is something rather different