On 03/01/2013 08:13 PM, Anthony Liguori wrote: > Eric Blake <ebl...@redhat.com> writes: > >> On 03/01/2013 04:59 PM, Anthony Liguori wrote: >>> I said this when seccomp was first introduced and I'll say it again. >>> blacklisting open() is a bad idea. DAC and MAC already exist and solve >>> this problem. We've got filesystem namespaces too. >> >> Let's explore that idea a bit further. What happens if libvirt decides >> to create a new filesystem namespace for qemu, where libvirt unmounts >> all non-local filesystems, as well as any file system that does not >> support SELinux labeling. Then all remaining filesystems, seen by qemu, >> will enforce SELinux semantics, and we can let qemu open() at will >> because the open will then be guarded by SELinux. The only remaining >> access is to files to the unmounted file systems, where fd passing from >> libvirt bypasses the fact that qemu can't see the file system. I could >> see that working, and it would still let us get rid of the selinux >> virt_use_nfs bool while still providing secure NFS out-of-the-box. And >> your argument is that virtio-rng should be pointed to a character >> device, never an NFS file, and therefore not using qemu_open() is no >> real loss because open() will not be blacklisted, just NFS file systems. >> Okay, maybe that will work. > > A simpler version would be to chroot the QEMU process but sure.
chroot is escapable, but you are correct that there are indeed ways of restricting open() on certain filesystems without blacklisting all open() in general. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
