Virtqemud wants to unlink /dev/urandom

Nikola Knazekova nknazeko at redhat.com
Wed Mar 16 11:40:31 UTC 2022


Hi guys,

Thank you very much for the detailed explanation.

With the mount namespace feature turned off, there were no SELinux denials.

Michal I saw your commit
<https://gitlab.com/libvirt/libvirt/-/commit/22188790cad490f51e73dabcac65736c3b8871a7>,
where firstly the existence of devices is checked. I assume when some
correction is required, virtqemud will still need unlink permission, right?

Nikola

On Mon, Mar 14, 2022 at 1:12 PM Michal Prívozník <mprivozn at redhat.com>
wrote:

> On 3/14/22 12:45, Martin Kletzander wrote:
> > [adding back libvir-list to the Cc]
> >
> > On Fri, Mar 11, 2022 at 03:55:03PM +0100, Nikola Knazekova wrote:
> >> Hey Martin,
> >>
> >> thanks for your resposne.
> >>
> >> I don't know if it is happening in the mount namespace. Can you look
> >> at the
> >> logs in attachment?
> >>
> >> It was happening on clear install on F35, F36 and on older versions
> >> probably too.
> >> But it is only an issue in the new selinux policy for libvirt. In old
> >> selinux policy is allowed for virtd to unlink /dev/urandom char files.
> >> I just wanted to be sure if it is ok to allow it for virtqemud.
> >>
> >
> > That actually might be the case, that it actually does set the context
> > on /dev/urandom correctly and then the unlink fails for virtqemud since
> > the selinux policy only accounts for libvirtd even though we switched to
> > modular daemons making virtqemud the one to do the work.
> >
> > @Michal can you confirm what I'm guessing here since you did a lot of
> > the mount namespace work which I presume is what contributes to the
> > issue here.
> >
> > In the meantime, would you mind trying this with the mount namespace
> > feature turned off in /etc/libvirt/qemu.conf like this:
> >
> > namespaces = []
> >
>
> Yeah, this will definitely help. So, a short introduction into how
> libvirt starts a QEMU guest. It creates a mount namespace so that QEMU
> doesn't have access to all the files in the system. In this namespace
> (which is per each QEMU process) firstly very few paths are populated
> independent of guest configuration (like /dev/null, /dev/random/,
> /dev/urandom, etc.) - the full list is accessible here:
>
> https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu.conf#L565
>
> (yes, it's the cgroup_device_acl list - because what you want to enable
> in CGroups you want to expose in the namespace)
>
> Then, the paths from domain XML are created using the following function:
>
>
> https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_namespace.c#L931
>
> This function is written in a fashion that allows files to exist and if
> needed [1] it simply unlink()-s existing file and creates it from
> scratch again. Now, since you configured TPM for your guest with
> /dev/urandom as a backend, this node is created twice. The first time
> among with other cgroup_device_acl files, the second because of TPM from
> your domain config.
>
> 1: needed is probably a bad word, and in fact we can be more clever
> about it. We might check whether given device already exists and if it
> has the same MAJ:MIN and act accordingly. The same applies for symlinks.
>
> Let me see if I can cook up a patch that implements this idea.
>
> Michal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20220316/6236d35e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fedora35-6.log
Type: text/x-log
Size: 4892 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20220316/6236d35e/attachment-0001.bin>


More information about the libvir-list mailing list