Re: [libvirt] [PATCH V9 3/3] Add support for file descriptor sets
On 03/12/2013 05:21 AM, Stefan Berger wrote:
> And here, these files support SELinux labeling, so maybe fd
passing is
> overkill, other than proof of concept that we are doing fd passing
> correctly. So, I'm debating on how much of this patch needs to be
> applied, or whether we should split it into smaller chunks to ease
> backporting of some portions to older libvirt without dragging in
> everything.
I misinterpreted your fd-passing related comments on TPM support for
QEMU and thought that this is where you wanted to move in general also
thinking that seccomp support for eliminating open() must be one goal.
I think my interpretation of the end goal changed in between my comments
on v1 and now on v9. That is, on the qemu list, it was pointed out to
me that we only NEED fd passing for NFS files; using fd passing
everywhere might be easier to code, but the only place where fd passing
adds security is with NFS files.
Actually, while I wrote this patch I also had a part that passed the
monitor via fd to QEMU, but obviously there is no support for this. This
could possibly eliminate the socket() call from QEMU. Knocking out open
and socket syscalls would then become dependent on which devices are
used by QEMU ( I suppose some devices still require open to be called in
the path somewhere ), thus making this configuration-dependent and
likely difficult to test. I guess the use-case where no SELinux support
is available is weak or non-existent so that seccomp would need to be used.
I don't know if seccomp in isolation is reasonable - SELinux can block
open() for NFS while allowing it for saner file systems that allow
selinux labeling, and seems like it is a tractable problem to determine
which files SELinux would block; whereas seccomp blindly blocking all
open() might be too much hassle to ever decently support.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 621 bytes)