Re: [libvirt-users] libvirtd via unix socket using system uri
On 4/30/19 3:15 PM, Peter Crowther wrote:
On Tue, 30 Apr 2019 at 10:48, Daniel P. Berrangé
<berrange(a)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(a)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