On Tue, 30 Apr 2019 at 10:48, Daniel P. Berrangé <berra...@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 <mpriv...@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 system, as that allows write of any config file. It'd be lovely to find a way of not requiring that. Knowing that a piece of software can't maliciously insert kernel modules, can't write or clear audit trails, and can't do raw I/O already considerably reduces the analysis. - Peter
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
