How secure is user-mode Linux, in terms of protecting the host system?

Question

Two questions about User-Mode Linux:

• Suppose that a privilege escalation attack is used to gain root in a UML guest. Assuming modern (3.0 or later) host and guest kernels, is it trivial to escape the sandbox, as with a chroot? Or is it more difficult?

• Is it possible to run a privilege escalation exploit against the host kernel directly, from within a UML guest? Or is bypassing the UML kernel not practical for an attacker?

Answer 1

I don't know how exactly a UML kernel is run on the host system. I'm entirely speculating, but my speculations might be useful if you can combine them with some documentation on UML implementations.

Privilege escalation in the guest with a guest-specific exploit

Being root on the guest kernel should essentially allow you to do whatever you want with the privileges of the PID that was used to run this kernel.

If running a UML kernel is done with UID 0 (which I would assume is unlikely), the process does not run in a PID namespace, and the process has been left with one of the many capabilities allowing full privileges, then you're in deep, deep trouble and should consider the whole host to be contaminated.

If that process runs with UID 0 outside a PID namespace but with some form of MAC enforcement, what it can do and how it can persist depends on the specific system. SELinux roles could come in as particularly handy to add extra protection. You're likely in trouble as well.

If the process runs with another UID, or is locked down into a PID namespace, you're more likely to be protected. The guest VM will be done for, but there should be limits to what your adversary can do and the rest of the host system could be decently protected.

Privilege escalation with an exploit also applying to the host

It's not unlikely that the host to your UML kernel is the same kernel. So, assuming an attacker has found a way to abuse an UML kernel it would be reasonable to assume they also have an exploit for the host kernel, except for:

• Namespaces and MAC might provide some amount of protection by ensuring that less of the Linux syscall interface is available and that might prevent your attacker from running the exploit.
• An exploit that is based on an untrusted module only present in that guest kernel would likewise not lead to a compromise of the host.