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