[libvirt] Problem configuring selective dropping of root
Stephan von Krawczynski
skraw.ml at ithnet.com
Thu Jul 11 08:23:04 UTC 2019
On Thu, 11 Jul 2019 10:07:11 +0200
Pavel Hrdina <phrdina at redhat.com> wrote:
> On Wed, Jul 10, 2019 at 11:56:38AM +0200, Stephan von Krawczynski wrote:
> > On Wed, 10 Jul 2019 09:56:35 +0200
> > Pavel Hrdina <phrdina at redhat.com> wrote:
> > > On Wed, Jul 10, 2019 at 12:01:18AM +0200, Stephan von Krawczynski
> > > wrote:
> > > > On Tue, 9 Jul 2019 14:26:08 +0200
> > > > Pavel Hrdina <phrdina at redhat.com> wrote:
> > > >
> > > > > [...]
> > > > >
> > > > > In addition if you would like to have only one VM as root:root you
> > > > > should keep the default config as nobody:kvm and use the root:root
> > > > > for that specific VM.
> > > > >
> > > > > Pavel
> > > >
> > > > Let me answer this part in another post.
> > > > Generally I agree with you. But there is one question: if I configure
> > > > libvirt to use nobody:kvm as user, how is it possible to start a qemu
> > > > with root privileges? I thought it not to be possible that it runs a
> > > > root process while its config says it should be nobody ...?
> > >
> > > That configuration is in /etc/libvirt/qemu.conf which configures things
> > > related to QEMU process and the user:group configuration tells how the
> > > QEMU process will be started. The system libvirtd daemon runs always as
> > > root:root in order to have permissions to execute QEMU process under any
> > > user and to configure a lot of other things when starting a VM.
> > >
> > > > I thought it can only _drop_ privileges from root to nobody, because
> > > > its primary user is root.
> > > > Or is it in fact always running as root, and only "fake-dropping" to
> > > > the configured user (maybe a spawned child), while still being able to
> > > > spawn other root processes?
> > >
> > > I'm not sure what do you mean by "fake-dropping", libvirt forks itself
> > > in order to create a new process where the QEMU binary is executed and
> > > the permissions are configured for that newly created process.
> > >
> > > All of this is true only for the system libvirt, that means if you use
> > > qemu:///system connection, for the session libvirt everything runs as
> > > your user and there is no session libvirt for root user.
> > >
> > > The XML and configuration that I've suggested should work as I've tried
> > > it before sending the mail.
> > >
> > > Pavel
> > Thank you for clearing things up a bit for me.
> > I am using arch linux (see OP) and the libvirt version gives:
> > virsh # version
> > Kompiliert gegen die Bibliothek: libvirt 5.4.0
> > Verwende Bibliothek: libvirt 5.4.0
> > Verwende API: QEMU 5.4.0
> > Laufender Hypervisor: QEMU 4.0.0
> > Using your seclabel with root:root in libvirt/qemu.conf throws:
> > virsh # start collabora
> > Fehler: Domain collabora konnte nicht gestartet werden
> > Fehler: Interner Fehler: process exited while connecting to monitor:
> > 2019-07-10T09:49:52.519211Z qemu-system-x86_64: -object
> > secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-18-collabora/master-key.aes:
> > Unable to read /var/lib/libvirt/qemu/domain-18-collabora/master-key.aes:
> > Failed to open file
> > “/var/lib/libvirt/qemu/domain-18-collabora/master-key.aes”: Permission
> > denied
> > Unfortunately I cannot verify what file permissions the requested file
> > has, as it is vanished as soon as the crash happens.
> > I bet though that it has root:root and the correctly set qemu user
> > nobody:kvm has no read rights. So obviously relabel does not work.
> > As it works on your side question is what's different? You are sure that
> > you did not try the other way round and seclabel to root:root for a setup
> > with standard user nobody:kvm. This would explain why you do not get this
> > error... I generally try not to patch around in libvirt or qemu or the
> > hosts' arch system. Which makes this probably at least a bug in the
> > distro...
> Since the conversation of solution for the issue continues in different
> part of this thread I would like to just point out that you should try
> doing it the other way around.
> You've stated in previous mails that you would like to have only one VM
> as root:root and the rest of the VMs as the default nobody:kvm. In
> general it's really bad idea to configure root:root as the default, as
> it creates unnecessary security risk for all of the VMs.
> Regardless of that, if there is a bug in libvirt when having root:root
> as default we should fix it.
I totally agree with you that root:root is not the right choice for the global
setup. I was thinking falsely that root:root would be required to be able to
drop the rights to nobody for some qemus instead of increasing from nobody to
root for one qemu.
Since I learned libvirt is running as root anyways obviously setting global
user to nobody is the right choice (which I did in the meantime).
And since we found (elsewhere in the thread) that it is indeed a dir
permission problem my trust in the libvirt project is at least 99% restored :-)
Could be 100% if libvirt would check and set the permissions correctly ... ;-)
More information about the libvir-list