Open Stack

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 :|