On 4/30/19 3:15 PM, Peter Crowther wrote:
On Tue, 30 Apr 2019 at 10:48, Daniel P. Berrangé <berrange@redhat.com> 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@redhat.com> 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