[kata-dev] Improving isolation in Kata

Boeuf, Sebastien sebastien.boeuf at intel.com
Mon Jul 23 22:34:11 UTC 2018


Hi Daniel,

Ok, got it about libvirt being root and being able to change any ownership on files and devices.
As we run our kata-runtime as root, it can exactly do the same thing as libvirt does, and I'd like
to understand the details about the way changing ownership works.

Does libvirt change the ownership of the device back to its initial ownership once it gets
"released" by Qemu (when Qemu terminates) ?

Also, the fies created will be owned by the non-root user being chosen, which modifies the
security associated with those files. When Qemu runs root, only root can access/modify
them on the host, but by running Qemu as non-root, they will be more accessible since they
won't be owned by root.

Thanks,
Sebastien
________________________________________
From: Daniel P. Berrangé [berrange at redhat.com]
Sent: Wednesday, July 18, 2018 12:14 AM
To: Boeuf, Sebastien
Cc: Stefan Hajnoczi; kata-dev at lists.katacontainers.io
Subject: Re: [kata-dev] Improving isolation in Kata

On Tue, Jul 17, 2018 at 10:25:53PM +0000, Boeuf, Sebastien wrote:
> Hi Stefan, Daniel,
>
> Thanks for the feedback here. I have just tried the virtfs-proxy-helper and it works
> like a charm, allowing me to run Qemu from a non root user. Now, I haven't tried
> this yet, but I wanted to know if you thought about any reason using virtio-net-pci
> would not work by using the vhost backend like this:
> -netdev tap,id=network-0,vhost=on,vhostfds=3:4:5:6:7:8:9:10,fds=11:12:13:14:15:16:17:18 -device driver=virtio-net-pci,netdev=network-0,mac=02:42:ac:11:00:02,mq=on,vectors=18

Yes, libvirt supports passing multiple FDs for vhost, and setting mq/vectors
properties.

> Same question about block devices. We're doing heavy uses of virtio-scsi in order
> to share a block device (our container rootfs) with the guest. Is it possible to run
> Qemu non root in this case ? Should I put the user running Qemu in the disk group
> so that Qemu can read/write to this block device ?

What happens is that the libvirtd daemon is running as root. When launching a
guest, it thus has privileges to change ownership of the block device so that
QEMU can access it while running as non-root. So there's no need to change
block device permissiosn or set group membership - libvirt will take care of
changing it for you.

> Last use case is VFIO for device passthrough. After we unbind the device from its
> driver on the host, should we change the ownership of the device created (something
> like /dev/vfio/X) after it has been bound to vfio-pci driver ?

Again, libvirt would take care of any permissions change that is required.

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



More information about the kata-dev mailing list