libvirt users - Apr 2019 - Re: libvirtd via unix socket using system uri

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.

Cheers,

- Peter

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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Tue, Apr 30, 2019 at 10:48:51AM +0100, Daniel P. Berrangé
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.
Opps, I mean cap_dac_override not cap_sys_admin but the point still stands.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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