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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list