Open Stack

Kata currently launches QEMU as user 'root' and I haven't found
isolation mechanisms that would confine the QEMU process in the event of
a guest escape.

Inevitably there will be a security bug that allows a malicious guest to
escape to QEMU, so it's important that the QEMU process is unprivileged
and isolated.

Running QEMU as 'root' simplifies 9p configuration by allowing the QEMU
process to access files with any uid/gid.  QEMU does support other 9p
configurations where the QEMU process does not run as root, including
the virtfs-proxy-helper privilege separation approach.

Are there any other reasons for running the QEMU process as root?

For comparison, libvirt launches QEMU as the unprivileged 'qemu' user
with a unique SELinux context.  This makes it much harder to access
other guests or escape to the host if the guest compromises QEMU.

Is there any work underway to improve isolation in Kata?

Two directions that come to mind are:

1. Design isolation from scratch for Kata, including unprivileged
   uid/gid, namespaces, and SELinux.  This requires changes to Kata
   because the QEMU process will not be able to open arbitrary files
   (e.g. device hotplug, 9p configuration).

   FWIW, relying on namespaces doesn't add a lot of security because if
   the guest is malicious, then that may well be because of a Linux
   namespaces security hole - the attacker could just use the same
   exploit again to escape from QEMU to the host.

2. Use libvirt-go (API) or libvirt-go-xml (XML) instead of govmm to get
   strong isolation.  This would also slim down virtcontainers and
   remove the dependency on govmm (no more command-line munging and
   defining object models for QEMU command-line concepts).

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180716/6b794df6/attachment.sig>