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

Re: [libvirt-users] libvirtd via unix socket using system uri



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 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

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