On 4/30/19 3:15 PM, Peter Crowther wrote:
On Tue, 30 Apr 2019 at 10:48, Daniel P. Berrangé <berrange@xxxxxxxxxx>
wrote:
On Tue, Apr 30, 2019 at 10:45:03AM +0100, Peter Crowther wrote:
On Tue, 30 Apr 2019 at 10:40, Michal Privoznik <mprivozn@xxxxxxxxxx>
wrote:
Is there any problem running libvirtd as root?
Yes, in the regulated environment in which I work! I have to do far
more
thorough threat analysis than I would do if I knew which capabilities it
had. So far, we've accepted the extra work; but it would be wonderful to
be able to run a locked-down virtualisation environment.
Libvirtd system mode will want cap_net_admin in order to setup TAP devices
and cap_sys_admin to manage disk permissions to grant QEMU access, at which
point you've lost any security benefit of running it unprivileged with
selective capabilities.
Would it fail hard without these, even if using (for example) pre-created
Ceph block storage, which is our use case? Or would it only fail when it
tried to make use of a capability that wasn't present? My reading of
capabilities is that behaviour is indistinguishable until you get an EPERM?
I agree that CAP_DAC_OVERRIDE (per your later mail) is game over for any
CAP_DAC_OVERRIDE won't be required if you don't need libvirt to
chown()/setfilecon() disk images (dynamic_ownership in qemu.conf).
CAP_SYS_ADMIN is going to be required if you want libvirt to mount some
nfs based storage pools/create namespaces (note that libvirt creates a
small namespace for qemu to run in - might need CAP_MKNOD then).
Long story short, why bother with /system if you can't use it and not
use /session instead?
Michal
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
