<div dir="ltr">On Tue, 30 Apr 2019 at 10:48, Daniel P. Berrangé <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Apr 30, 2019 at 10:45:03AM +0100, Peter Crowther wrote:<br>
> On Tue, 30 Apr 2019 at 10:40, Michal Privoznik <<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>> wrote:<br>
> <br>
> > Is there any problem running libvirtd as root?<br>
> ><br>
> > Yes, in the regulated environment in which I work!  I have to do far more<br>
> thorough threat analysis than I would do if I knew which capabilities it<br>
> had.  So far, we've accepted the extra work; but it would be wonderful to<br>
> be able to run a locked-down virtualisation environment.<br>
<br>
Libvirtd system mode will want cap_net_admin in order to setup TAP devices<br>
and cap_sys_admin to manage disk permissions to grant QEMU access, at which<br>
point you've lost any security benefit of running it unprivileged with<br>
selective capabilities.<br>
<br></blockquote><div>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?<br></div><div><br></div><div>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.</div><div><br></div><div>- Peter<br></div></div></div>