qemu-kvm invoked manually: qemu-kvm -hda /dev/null -boot n -net nic -net tap,/etc/qemu-ifup It NFS mounts mounts its root filesystem from a chroot on the host. Mount seemingly works enough for the thin client to operate, but during operation I see this AVC denial on the host. type=AVC msg=audit(1193803835.861:74): avc: denied { getattr } for pid=2153 comm="rpc.mountd" path="/dev/kvm" dev=tmpfs ino=5849 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file kvm-36-7.fc8 selinux-policy-3.0.8-42.fc8
Are you exporting the server's /dev over NFS? Because that's what it looks like and that's almost certainly something you _don't_ want to do as it would let the LTSP clients muck with things in /dev of the server
Well what is /dev/kvm? It is not labeled. I have no idea what to label it. Do we need a new type?
It's the device used for communication between kvm userspace and kernel. And since we're not currently doing anything to confine kvm, having it as device_t is reasonable.
Ok I added a kvm_device_t to selinux-policy-3.0.8-43.fc8 Most domains can not look at device_t so it will generate avc;s if not just for getattr types.
I don't see why rpc.mounted is trying to open /dev/kvm at all. It has no business touching that whatsoever. It smells like a leaked file descriptor to me.
leaked file descriptor from what? Note: This doesn't actually prevent NFS from working.
This is most likely rpc.mountd doing a getattr on evey chr_file in /dev. If it does the equivalent of ls -lZ /dev, you will get this getattr violation. Existing selinux policy has dev_dontaudit_getattr_all_blk_files(nfsd_t) dev_dontaudit_getattr_all_chr_files(nfsd_t) The problem is device_t was not considered a valid label for a chr_file so these dontaudit lines did not take effect.
Bulk closing all bugs in Fedora updates in the modified state. If you bug is not fixed, please reopen.