On Tue, Oct 30, 2018 at 03:53:59PM +0000, Daniel P. Berrangé wrote:
On Tue, Oct 30, 2018 at 04:47:32PM +0100, Michal Privoznik wrote:Well, caching owner + seclabels + ACLs won't help either. What if user loads some profile into AppArmor or something that denies previously allowed access to /dev/kvm (or vice versa)? What I am saying is that there are some security models which base their decisions on something else than file attributes.The virFileAccessibleAs check for /dev/kvm was put in their to ensure that we correctly report usability of KVM in the capabilities XML according to file permissions/ownership. Essentially KVM is not usable until the udev rule is applied to change permissions to world accessible or to set the kvm group.
Can libvirt be run sooner than the permissions are set up during regular start-up, or this is just for the case of the user randomly touching the permissions? IIRC the problem was that users with vmx disabled in BIOS setup needed to delete libvirt's qemuCaps cache manually after enabling it even after restarting the system. To catch that, all we'd have to do is run the check once per daemon lifetime,
I don't think we need to care aout selinux/apparmor restrictions - just need to be no worse than what we cope with today, which is just perms and owner/group.
but that could be considered worse according to this metric. Jano
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
