On Mon, Jul 16, 2018 at 10:04:05PM +0000, Larrew, Jesse wrote:
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
Hi Stefan,
I did some research previously into filesystem encryption for the container guest. This was intended as an additional control for SEV containers. (Memory encryption is more valuable if the guest container filesystem isn't mounted unencrypted in the host.)
Yeah, with SEV you would not want the container filesystem mounted in the host, as that puts a hole in the security SEV offers.
Of the two options that you outline above, option #2 (libvirt integration) seems like the right choice architecturally. (I'll have to update my SEV patches, but libvirt integration will likely make them smaller overall.) This may also address my filesystem concerns as well. Does the SELinux policy used by libvirt also protect the mount directory for the container filesystem?
Yes, the SELinux (sVirt) policy applied by libvirt confines every resource used by the guest. Each guest VM gets a common base label svirt_t, combined with a unique category (eg c123,c643). Any files/resources that are to be accessible by the guest must be labelled with a label svirt_image_t combined with the matching category (c123,c643). Normally libvirt will automagically assign the right svirt_image_t label to all files that the guest is configured to access (in its XML config). With 9p filesystem passthrough there is a caveat that libvirt won't (currently) recursively label an entire tree itself. The app using libvirt, however, still has the ability todoo this labelling upfront to grant access as needed. FYI, libvirt gained support for the SEV feature in its recent release. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|