libvirt users - Apr 2019 - Re: 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

On 4/30/19 3:15 PM, Peter Crowther wrote:
> 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
CAP_DAC_OVERRIDE won't be required if you don't need libvirt to 
chown()/setfilecon() disk images (dynamic_ownership in qemu.conf).
CAP_SYS_ADMIN is going to be required if you want libvirt to mount some 
nfs based storage pools/create namespaces (note that libvirt creates a 
small namespace for qemu to run in - might need CAP_MKNOD then).

Long story short, why bother with /system if you can't use it and not 
use /session instead?

Michal

On Tue, 30 Apr 2019 at 16:43, Michal Privoznik <mprivozn@redhat.com>
wrote:
> Long story short, why bother with /system if you can't use it and not
> use /session instead?
>
> Because according to the FAQ, /session isn't suitable for my use:
   - You will definitely want to use qemu:///system if your VMs are acting
   as servers. VM autostart on host boot only works for 'system' [Yes,
my VMs
   are acting as servers]
   - the root libvirtd instance has necessary permissions to use proper
   networkings via bridges or virtual networks. [Yes, I use OVS, with quite a
   complex bridge+VLAN system configured at boot]
   - qemu:///session has a serious drawback: [...] the only out of the box
   network option is qemu's usermode networking, which has nonobvious
   limitations, so its usage is discouraged.

(Source:
https://wiki.libvirt.org/page/FAQ#What_is_the_difference_between_qemu:.2F.2F.2Fsystem_and_qemu:.2F.2F.2Fsession.3F_Which_one_should_I_use.3F
)

So I have to use /system, according to the FAQ.  But it'd be nice to nail
the daemon down to reduce the attack surface.

- Peter