Re: libvirtd via unix socket using system uri

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux