12:10 p.m.
Team,
I note that libvertd runs as root user that is against the least privilege security
model.
root 307278 1 0 Jun20 ? 04:16:46 /usr/sbin/libvirtd -listen
Appreciate pointers to alternate options that user could configure as a potential
mitigation plan?
Thanks,
-Anshul
12:24 p.m.
On 07/30/2015 11:10 AM, Anshul Arora (akarora) wrote:
Team,
I note that libvertd runs as root user that is against the least privilege security
model.
root 307278 1 0 Jun20 ? 04:16:46 /usr/sbin/libvirtd -listen
Sadly, that IS the least privilege required for successfully running
qemu:///system or lxc:/// guests.
Appreciate pointers to alternate options that user could configure as a potential
mitigation plan?
Use qemu:///session connections - that runs a separate libvirtd process
as the current user, just fine. Without privileges, your guests will
have a harder time using networking, but that's what you'd expect.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
1:15 p.m.
Eric Blake <eblake(a)redhat.com> writes:
On 07/30/2015 11:10 AM, Anshul Arora (akarora) wrote:
> Team,
>
> I note that libvertd runs as root user that is against the least privilege security
model.
>
> root 307278 1 0 Jun20 ? 04:16:46 /usr/sbin/libvirtd -listen
Sadly, that IS the least privilege required for successfully running
qemu:///system or lxc:/// guests.
>
>
> Appreciate pointers to alternate options that user could configure as a potential
mitigation plan?
Use qemu:///session connections - that runs a separate libvirtd process
as the current user, just fine. Without privileges, your guests will
have a harder time using networking, but that's what you'd expect.
To enhance this experience, make sure that /dev/kvm is writable by the
current user, and configure qemu-bridge-helper (and make sure
it's setuid).
3284
days inactive
3284
days old
2 comments
3 participants
participants (3)
-
Anshul Arora (akarora) -
Eric Blake -
Spencer Baugh