Hi,

What is the path for the system.token file?
Is this file present and used the same way on RHEL 8, too?

I am also confused regarding the fedora version: bz metadata is for F34, audit alert is for F33, the comment for F35. Does it mean the issue applies to all of them?

I am sorry, I haven't noticed this reference /run/libvirt/common/system.token, so the path is known.

Note that this system.token file will be created by whichever of the libvirt related daemons is the first to need it. It is intended to be accessible to all libvirt daemons. Essentially it is a way for 1 libvirt daemon to validate that it is talking to another libvirt, as opposed to a 3rd party libvirt client. Libvirtd will acquire fcntl() locks on this file when first creating it to ensure race-free access.

Niki,

Is dealing with this token file covered in the new libvirt policy?

(In reply to Zdenek Pytela from comment #1)
> Hi,
> 
> What is the path for the system.token file?
> Is this file present and used the same way on RHEL 8, too?
Yes I think because the libvirt are build from the same version as what in Fedora.
Here are the labels of system.token and virtlogd:
➜  ~ ls -aZ /run/libvirt/common/system.token
system_u:object_r:virt_var_run_t:s0 /run/libvirt/common/system.token
➜  ~ ps auxZ|grep virtlogd
system_u:system_r:virtlogd_t:s0-s0:c0.c1023 root 1977217 0.0  0.4 379388 15476 ? Ss   May24   0:00 /usr/sbin/virtlogd

> 
> I am also confused regarding the fedora version: bz metadata is for F34,
> audit alert is for F33, the comment for F35. Does it mean the issue applies
> to all of them?

Yes. Both selinux-policy-targeted-3.14.6-37.fc33.noarch selinux-policy-34.7-1.fc35.noarch have this issue.

Originally the bug was found on FC33 selinux-policy-targeted-3.14.6-37.fc33.noarch. Now I reproduce it on FC34 selinux-policy-targeted-34.8-1.fc34.noarch.

I think the bz metadata for F34 is acceptable here.

This is the workaround I've applied:

  $ cat libvirt.audit.log 
  type=AVC msg=audit(1622021545.981:3626): avc:  denied  { read append } for  pid=133490 comm="virtlogd" name="system.token" dev="tmpfs" ino=3828 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=0

  $ rm -rf local-libvirt.* tmp/ && audit2allow -R -m local-libvirt >local-libvirt.te <libvirt.audit.log && make -f /usr/share/selinux/devel/Makefile local-libvirt.pp && sudo semodule -i local-libvirt.pp
  [...]
  Compiling targeted local-libvirt module
  Creating targeted local-libvirt.pp policy package
  rm tmp/local-libvirt.mod.fc tmp/local-libvirt.mod

After restarting libvirtd and virtlogd, I can once again start VMs.

> Note that this system.token file will be created by whichever of the libvirt
> related daemons is the first to need it. It is intended to be accessible to
> all libvirt daemons. Essentially it is a way for 1 libvirt daemon to
> validate that it is talking to another libvirt, as opposed to a 3rd party
> libvirt client. Libvirtd will acquire fcntl() locks on this file when first
> creating it to ensure race-free access.
Daniel,

Do I understand correctly that in SELinux policy this token file should have a different type to virt_var_run_t so that only authorised services can read and append it? Which particular services?

Currently, these services have read access to virt_var_run_t directly allowed, and about 30 others utilising attributes:
# sesearch -A -t virt_var_run_t -c file -p read -dt
allow dhcpc_t virt_var_run_t:file { append create getattr ioctl link lock open read rename setattr unlink watch watch_reads write };
allow dnsmasq_t virt_var_run_t:file { getattr ioctl lock open read };
allow fenced_t virt_var_run_t:file { getattr ioctl lock open read };
allow sanlock_t virt_var_run_t:file { getattr ioctl lock open read };


The token support seems to have been added by:
https://github.com/libvirt/libvirt/commit/d5d011f76745a9764464c9066223b17c4058f83f

Is there a scenario or a test suite available to gather all denials?(In reply to Daniel Berrangé from comment #3)

(In reply to Zdenek Pytela from comment #7)
> > Note that this system.token file will be created by whichever of the libvirt
> > related daemons is the first to need it. It is intended to be accessible to
> > all libvirt daemons. Essentially it is a way for 1 libvirt daemon to
> > validate that it is talking to another libvirt, as opposed to a 3rd party
> > libvirt client. Libvirtd will acquire fcntl() locks on this file when first
> > creating it to ensure race-free access.
> Daniel,
> 
> Do I understand correctly that in SELinux policy this token file should have
> a different type to virt_var_run_t so that only authorised services can read
> and append it? Which particular services?

Any of the libvirt daemons (libvirtd, and virt{qemu,lxc,log,lock,etc...}d) should be allowed to both create/read this file, and acquire fcntl locks on it.

This file contains a short random set of bytes that provide a secret token shared between any of the libvirt daemons.

The first libvirtd daemon that starts up will create this file, and others will later read its content.

No access should be allowed to any non-libvirt daemon process.

I put the file in the /run/libvirt/common directory to make it clear that it is a file shared across all libvirt daemons, as well as to make it easier to separate from non-libvirt processes that might otherwise access /run/libvirt

> 
> Currently, these services have read access to virt_var_run_t directly
> allowed, and about 30 others utilising attributes:
> # sesearch -A -t virt_var_run_t -c file -p read -dt
> allow dhcpc_t virt_var_run_t:file { append create getattr ioctl link lock
> open read rename setattr unlink watch watch_reads write };
> allow dnsmasq_t virt_var_run_t:file { getattr ioctl lock open read };
> allow fenced_t virt_var_run_t:file { getattr ioctl lock open read };
> allow sanlock_t virt_var_run_t:file { getattr ioctl lock open read };

None of these should be allowed to access the token file.

> The token support seems to have been added by:
> https://github.com/libvirt/libvirt/commit/
> d5d011f76745a9764464c9066223b17c4058f83f
> 
> Is there a scenario or a test suite available to gather all denials?(In
> reply to Daniel Berrangé from comment #3)

I think you only need two scenarios - one to trigger the file creation codepath, and one for the file read codepath. 

This should be achieved by installing the new libvirt version referenced in the initial comments. 

Then attempt to start & stop a guest.  This should trigger token creation

Then re-sttart the libvirtd.service unit, and do the same start & stop guest action. This should trigger reading the existing token.

(In reply to Daniel Berrangé from comment #8)
> Any of the libvirt daemons (libvirtd, and virt{qemu,lxc,log,lock,etc...}d)
> should be allowed to both create/read this file, and acquire fcntl locks on
> it.
> 
> This file contains a short random set of bytes that provide a secret token
> shared between any of the libvirt daemons.
> 
> The first libvirtd daemon that starts up will create this file, and others
> will later read its content.
> 
> No access should be allowed to any non-libvirt daemon process.
> 
> I put the file in the /run/libvirt/common directory to make it clear that it
> is a file shared across all libvirt daemons, as well as to make it easier to
> separate from non-libvirt processes that might otherwise access /run/libvirt
While still working on setting up the machine, I think we can get to the support in selinux-policy with two independent solutions, applying either of them or both:
- label /run/libvirt/common with, say, virt_common_var_run_t
- label the token file with virt_common_systemtoken_var_run_t
and allow the access as requested by starting/stopping the services.

Which services need access to the content in /run/libvirt/common, only the libvirt daemons or also other ones?

This is the list of direct permissions to virt_var_run_t in F34:

beaker-f34# sesearch -A -t virt_var_run_t -c dir -dt
allow dhcpc_t virt_var_run_t:dir { add_name ioctl lock read remove_name write };
allow dnsmasq_t virt_var_run_t:dir { add_name ioctl lock read remove_name write };
allow named_filetrans_domain virt_var_run_t:dir { add_name getattr ioctl lock open read remove_name search write };
allow svirt_kvm_net_t virt_var_run_t:dir { add_name ioctl lock read remove_name write };
allow svirt_t virt_var_run_t:dir { add_name remove_name write };
allow svirt_tcg_t virt_var_run_t:dir { add_name remove_name write };
allow virsh_t virt_var_run_t:dir { add_name ioctl lock read remove_name write };
allow virtlogd_t virt_var_run_t:dir { add_name ioctl lock read remove_name write };

beaker-f34# sesearch -A -t virt_var_run_t -c file -dt
allow dhcpc_t virt_var_run_t:file { append create getattr ioctl link lock open read rename setattr unlink watch watch_reads write };
allow dnsmasq_t virt_var_run_t:file { getattr ioctl lock open read };
allow fenced_t virt_var_run_t:file { getattr ioctl lock open read };
allow sanlock_t virt_var_run_t:file { getattr ioctl lock open read };
allow svirt_t virt_var_run_t:file { create getattr open read unlink write };
allow svirt_tcg_t virt_var_run_t:file { create getattr open read unlink write }

(In reply to Zdenek Pytela from comment #9)
> (In reply to Daniel Berrangé from comment #8)
> > Any of the libvirt daemons (libvirtd, and virt{qemu,lxc,log,lock,etc...}d)
> > should be allowed to both create/read this file, and acquire fcntl locks on
> > it.

snip

> While still working on setting up the machine, I think we can get to the
> support in selinux-policy with two independent solutions, applying either of
> them or both:
> - label /run/libvirt/common with, say, virt_common_var_run_t
> - label the token file with virt_common_systemtoken_var_run_t
> and allow the access as requested by starting/stopping the services.
> 
> Which services need access to the content in /run/libvirt/common, only the
> libvirt daemons or also other ones?

As above, only the libvirt daemons.

Nothing external to libvirt should be allowed.

Off different systems, I succeeded with the installation only on F35. I think I don't need anything else now, I'll come back once the solution is ready.

----
type=PROCTITLE msg=audit(06/09/2021 05:50:20.144:251) : proctitle=/usr/sbin/virtlogd 
type=PATH msg=audit(06/09/2021 05:50:20.144:251) : item=1 name=/run/libvirt/common/system.token inode=1048 dev=00:1a mode=file,600 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:virt_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=PATH msg=audit(06/09/2021 05:50:20.144:251) : item=0 name=/run/libvirt/common/ inode=1047 dev=00:1a mode=dir,700 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:virt_var_run_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(06/09/2021 05:50:20.144:251) : cwd=/ 
type=SYSCALL msg=audit(06/09/2021 05:50:20.144:251) : arch=x86_64 syscall=openat success=yes exit=14 a0=0xffffff9c a1=0x558e9a9a94f0 a2=O_RDWR|O_CREAT|O_APPEND a3=0x180 items=2 ppid=1 pid=755 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=virtlogd exe=/usr/sbin/virtlogd subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(06/09/2021 05:50:20.144:251) : avc:  denied  { open } for  pid=755 comm=virtlogd path=/run/libvirt/common/system.token dev="tmpfs" ino=1048 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=1 
type=AVC msg=audit(06/09/2021 05:50:20.144:251) : avc:  denied  { read append } for  pid=755 comm=virtlogd name=system.token dev="tmpfs" ino=1048 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=1
----
type=PROCTITLE msg=audit(06/09/2021 05:50:20.148:252) : proctitle=/usr/sbin/virtlogd
type=SYSCALL msg=audit(06/09/2021 05:50:20.148:252) : arch=x86_64 syscall=fcntl success=yes exit=0 a0=0xe a1=F_SETLKW a2=0x7fff00ddef70 a3=0x180 items=0 ppid=1 pid=755 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=virtlogd exe=/usr/sbin/virtlogd subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(06/09/2021 05:50:20.148:252) : avc:  denied  { lock } for  pid=755 comm=virtlogd path=/run/libvirt/common/system.token dev="tmpfs" ino=1048 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=1
----
type=PROCTITLE msg=audit(06/09/2021 05:50:20.149:253) : proctitle=/usr/sbin/virtlogd
type=PATH msg=audit(06/09/2021 05:50:20.149:253) : item=0 name= inode=1048 dev=00:1a mode=file,600 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:virt_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(06/09/2021 05:50:20.149:253) : cwd=/
type=SYSCALL msg=audit(06/09/2021 05:50:20.149:253) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=0xe a1=0x7f4e7947d95a a2=0x7fff00ddefc0 a3=0x1000 items=1 ppid=1 pid=755 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=virtlogd exe=/usr/sbin/virtlogd subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(06/09/2021 05:50:20.149:253) : avc:  denied  { getattr } for  pid=755 comm=virtlogd path=/run/libvirt/common/system.token dev="tmpfs" ino=1048 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=1

I've submitted a Fedora PR to support the "common" directory usage:
https://github.com/fedora-selinux/selinux-policy/pull/777

Higher level description:
- label /run/libvirt/common with virt_common_var_run_t
- it is only the libvirtd service which creates /run/libvirt/common directory
- virtd_t and virtlogd_t domains can open, read, lock, append files in this directory

where (not all these files may be currently present)
virtd_t is a label of process started from these executables:
/usr/libexec/qemu-pr-helper
/usr/sbin/libvirtd
/usr/bin/virt-who
/usr/bin/qemu-pr-helper
/usr/sbin/condor_vm-gahp
/usr/sbin/virtinterfaced
/usr/sbin/virtlxcd
/usr/sbin/virtnetworkd
/usr/sbin/virtnodedevd
/usr/sbin/virtnwfilterd
/usr/sbin/virtqemud
/usr/sbin/virtsecretd
/usr/sbin/virtstoraged
/usr/sbin/virtvboxd
/usr/sbin/virtvzd
/usr/sbin/virtxend
/usr/bin/imagefactory
/usr/bin/imgfac\.py
/usr/bin/vios-proxy-host
/usr/bin/vios-proxy-guest
/usr/share/vdsm/vdsm
/usr/share/vdsm/respawn
/usr/share/vdsm/supervdsmServer
/usr/share/vdsm/daemonAdapter
/usr/bin/nova-compute
/usr/lib/virt-sysprep/firstboot.sh

and virtlogd_t is a label of process started from these executables:
/usr/sbin/virtlockd
/usr/sbin/virtlogd

I am unable though to set up the machine any longer, I'd appreciate access to a running system, or if you can test Fedora packages available in the PR: Show all checks -> build-rpm -> Details -> Artifacts -> rpms

This is the updates list of steps which worked for me on a clean machine:
dnf install setools-console selinux-policy-devel -y
dnf install rpm-build librados-devel librbd-devel numactl-devel numad xen-devel -y
dnf builddep libvirt -y
git clone https://gitlab.com/libvirt/libvirt --depth 1
cd libvirt
meson build
cd build
meson dist
mkdir -p ~/rpmbuild/SOURCES/../SPECS/../RPMS/x86_64/
cp meson-dist/libvirt-*.tar.xz ~/rpmbuild/SOURCES
cp libvirt.spec ~/rpmbuild/SPECS
rpmbuild -ba ~/rpmbuild/SPECS/libvirt.spec

systemctl start libvirtd
virsh create hhan.xml
virsh destroy hhan.xml
systemctl restart libvirtd
virsh create hhan.xml
virsh destroy hhan.xml

But, depending on other circumstances, I keep receiving one of the following errors:
error: unsupported configuration: Emulator '/usr/bin/qemu-system-x86_64' does not support virt type 'kvm'
error: unsupported configuration: Emulator '/usr/libexec/qemu-kvm' does not support virt type 'kvm'
error: Cannot check QEMU binary /usr/bin/qemu-system-x86_64: No such file or directory

Han,

Could you test if the selinux-policy draft is sufficient to back the libvirt feature? Either with the build available in Fedora 34/35 PR, or anywhere with the following steps:

1. Install devel package
dnf install setools-console selinux-policy-devel -y

2. Create a local selinux policy module

  # cat local_virt.fc
/var/run/libvirt/common(/.*)?          gen_context(system_u:object_r:virt_common_var_run_t,s0)
  # cat local_virt.te
policy_module(local_virt, 1.0)

gen_require(`
        type virt_var_run_t;
        type virtd_t;
        type virtlogd_t;
')

type virt_common_var_run_t;
files_pid_file(virt_common_var_run_t)

allow virtd_t virt_common_var_run_t:file { append_file_perms read_file_perms };
manage_dirs_pattern(virtd_t, virt_common_var_run_t, virt_common_var_run_t)
manage_files_pattern(virtd_t, virt_common_var_run_t, virt_common_var_run_t)
filetrans_pattern(virtd_t, virt_var_run_t, virt_common_var_run_t, dir, "common")

allow virtlogd_t virt_common_var_run_t:file { append_file_perms read_file_perms };
manage_files_pattern(virtlogd_t, virt_common_var_run_t, virt_common_var_run_t)

  # make -f /usr/share/selinux/devel/Makefile local_virt.pp
  # semodule -i local_virt.pp

3. Reproduce the scenario
4. Look for avc denials
ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent

(In reply to Zdenek Pytela from comment #13)
> Han,
> 
> Could you test if the selinux-policy draft is sufficient to back the libvirt
> feature? Either with the build available in Fedora 34/35 PR, or anywhere
> with the following steps:
> 
> 1. Install devel package
> dnf install setools-console selinux-policy-devel -y
> 
> 2. Create a local selinux policy module
> 
>   # cat local_virt.fc
> /var/run/libvirt/common(/.*)?         
> gen_context(system_u:object_r:virt_common_var_run_t,s0)
>   # cat local_virt.te
> policy_module(local_virt, 1.0)
> 
> gen_require(`
>         type virt_var_run_t;
>         type virtd_t;
>         type virtlogd_t;
> ')
> 
> type virt_common_var_run_t;
> files_pid_file(virt_common_var_run_t)
> 
> allow virtd_t virt_common_var_run_t:file { append_file_perms read_file_perms
> };
> manage_dirs_pattern(virtd_t, virt_common_var_run_t, virt_common_var_run_t)
> manage_files_pattern(virtd_t, virt_common_var_run_t, virt_common_var_run_t)
> filetrans_pattern(virtd_t, virt_var_run_t, virt_common_var_run_t, dir,
> "common")
> 
> allow virtlogd_t virt_common_var_run_t:file { append_file_perms
> read_file_perms };
> manage_files_pattern(virtlogd_t, virt_common_var_run_t,
> virt_common_var_run_t)
> 
>   # make -f /usr/share/selinux/devel/Makefile local_virt.pp
>   # semodule -i local_virt.pp
> 
> 3. Reproduce the scenario
> 4. Look for avc denials
> ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent

Did as above with libvirt v7.4.0-110-gf14ca48ef4 selinux-policy-34.11-1.fc34.noarch, bug was reproduced again:
➜  ~ virsh create rhel9.xml
error: Failed to create domain from rhel9.xml
error: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied

➜  ~ ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent
----
type=AVC msg=audit(06/15/2021 03:53:47.442:349) : avc:  denied  { read append } for  pid=1480 comm=virtlogd name=system.token dev="tmpfs" ino=1037 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=0 
----
type=AVC msg=audit(06/15/2021 03:54:18.481:414) : avc:  denied  { read append } for  pid=1520 comm=virtlogd name=system.token dev="tmpfs" ino=1037 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=0

(In reply to Han Han from comment #14)
> (In reply to Zdenek Pytela from comment #13)
> > Han,
> > 
> > Could you test if the selinux-policy draft is sufficient to back the libvirt
> > feature? Either with the build available in Fedora 34/35 PR, or anywhere
> > with the following steps:
> > 
> > 1. Install devel package
> > dnf install setools-console selinux-policy-devel -y
> > 
> > 2. Create a local selinux policy module
> > 
> >   # cat local_virt.fc
> > /var/run/libvirt/common(/.*)?         
> > gen_context(system_u:object_r:virt_common_var_run_t,s0)
> >   # cat local_virt.te
> > policy_module(local_virt, 1.0)
> > 
> > gen_require(`
> >         type virt_var_run_t;
> >         type virtd_t;
> >         type virtlogd_t;
> > ')
> > 
> > type virt_common_var_run_t;
> > files_pid_file(virt_common_var_run_t)
> > 
> > allow virtd_t virt_common_var_run_t:file { append_file_perms read_file_perms
> > };
> > manage_dirs_pattern(virtd_t, virt_common_var_run_t, virt_common_var_run_t)
> > manage_files_pattern(virtd_t, virt_common_var_run_t, virt_common_var_run_t)
> > filetrans_pattern(virtd_t, virt_var_run_t, virt_common_var_run_t, dir,
> > "common")
> > 
> > allow virtlogd_t virt_common_var_run_t:file { append_file_perms
> > read_file_perms };
> > manage_files_pattern(virtlogd_t, virt_common_var_run_t,
> > virt_common_var_run_t)
> > 
> >   # make -f /usr/share/selinux/devel/Makefile local_virt.pp
> >   # semodule -i local_virt.pp
> > 
> > 3. Reproduce the scenario
> > 4. Look for avc denials
> > ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent
> 
> Did as above with libvirt v7.4.0-110-gf14ca48ef4
> selinux-policy-34.11-1.fc34.noarch, bug was reproduced again:
The pull request has not been merged yet and pushed to Fedora, it's needed to use the build attached to the PR
https://github.com/fedora-selinux/selinux-policy/pull/777
Show all checks -> build-rpm -> Details -> Artifacts -> rpms

or create a local policy module as described.

> ➜  ~ virsh create rhel9.xml
> error: Failed to create domain from rhel9.xml
> error: can't connect to virtlogd: Unable to open system token
> /run/libvirt/common/system.token: Permission denied
> 
> ➜  ~ ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent
> ----
> type=AVC msg=audit(06/15/2021 03:53:47.442:349) : avc:  denied  { read
> append } for  pid=1480 comm=virtlogd name=system.token dev="tmpfs" ino=1037
> scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=0 
> ----
> type=AVC msg=audit(06/15/2021 03:54:18.481:414) : avc:  denied  { read
> append } for  pid=1520 comm=virtlogd name=system.token dev="tmpfs" ino=1037
> scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=0

Then the directory should be labeled with virt_common_var_run_t and the access allowed.

(In reply to Zdenek Pytela from comment #15)
> (In reply to Han Han from comment #14)
> > (In reply to Zdenek Pytela from comment #13)
> > > Han,
> > > 
> > > Could you test if the selinux-policy draft is sufficient to back the libvirt
> > > feature? Either with the build available in Fedora 34/35 PR, or anywhere
> > > with the following steps:
> > > 
> > > 1. Install devel package
> > > dnf install setools-console selinux-policy-devel -y
> > > 
> > > 2. Create a local selinux policy module
> > > 
> > >   # cat local_virt.fc
> > > /var/run/libvirt/common(/.*)?         
> > > gen_context(system_u:object_r:virt_common_var_run_t,s0)
> > >   # cat local_virt.te
> > > policy_module(local_virt, 1.0)
> > > 
> > > gen_require(`
> > >         type virt_var_run_t;
> > >         type virtd_t;
> > >         type virtlogd_t;
> > > ')
> > > 
> > > type virt_common_var_run_t;
> > > files_pid_file(virt_common_var_run_t)
> > > 
> > > allow virtd_t virt_common_var_run_t:file { append_file_perms read_file_perms
> > > };
> > > manage_dirs_pattern(virtd_t, virt_common_var_run_t, virt_common_var_run_t)
> > > manage_files_pattern(virtd_t, virt_common_var_run_t, virt_common_var_run_t)
> > > filetrans_pattern(virtd_t, virt_var_run_t, virt_common_var_run_t, dir,
> > > "common")
> > > 
> > > allow virtlogd_t virt_common_var_run_t:file { append_file_perms
> > > read_file_perms };
> > > manage_files_pattern(virtlogd_t, virt_common_var_run_t,
> > > virt_common_var_run_t)
> > > 
> > >   # make -f /usr/share/selinux/devel/Makefile local_virt.pp
> > >   # semodule -i local_virt.pp
> > > 
> > > 3. Reproduce the scenario
> > > 4. Look for avc denials
> > > ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent
> > 
> > Did as above with libvirt v7.4.0-110-gf14ca48ef4
> > selinux-policy-34.11-1.fc34.noarch, bug was reproduced again:
> The pull request has not been merged yet and pushed to Fedora, it's needed
> to use the build attached to the PR
> https://github.com/fedora-selinux/selinux-policy/pull/777
> Show all checks -> build-rpm -> Details -> Artifacts -> rpms
> 
> or create a local policy module as described.
Yes. In the previous results I created the local_virt.pp and installed to by `semodule -i`.
> 
> > ➜  ~ virsh create rhel9.xml
> > error: Failed to create domain from rhel9.xml
> > error: can't connect to virtlogd: Unable to open system token
> > /run/libvirt/common/system.token: Permission denied
> > 
> > ➜  ~ ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent
> > ----
> > type=AVC msg=audit(06/15/2021 03:53:47.442:349) : avc:  denied  { read
> > append } for  pid=1480 comm=virtlogd name=system.token dev="tmpfs" ino=1037
> > scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023
> > tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=0 
> > ----
> > type=AVC msg=audit(06/15/2021 03:54:18.481:414) : avc:  denied  { read
> > append } for  pid=1520 comm=virtlogd name=system.token dev="tmpfs" ino=1037
> > scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023
> > tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=0
> 
> Then the directory should be labeled with virt_common_var_run_t and the
> access allowed.

Then I removed the dir /run/libvirt/common/ and restart libvirtd+virtlogd. The issue is not reproduced.
The selinux label:
➜  ~ ls /run/libvirt/common/ -alZ 
total 4
drwx------.  2 root root system_u:object_r:virt_common_var_run_t:s0  60 Jun 15 07:14 .
drwxr-xr-x. 13 root root system_u:object_r:virt_var_run_t:s0        380 Jun 15 07:14 ..
-rw-------.  1 root root system_u:object_r:virt_common_var_run_t:s0  32 Jun 15 07:14 system.token

Our beaker tests failed due to this issue.

Below is our manual test:

virsh # start mq-vhu-tunnel 
error: Failed to start domain 'mq-vhu-tunnel'
error: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied

This is now blocking our 8.5 and 9.0 OVS testing.

(In reply to Jean-Tsung Hsiao from comment #17)
> Our beaker tests failed due to this issue.
> 
> Below is our manual test:
> 
> virsh # start mq-vhu-tunnel 
> error: Failed to start domain 'mq-vhu-tunnel'
> error: can't connect to virtlogd: Unable to open system token
> /run/libvirt/common/system.token: Permission denied
> 
> This is now blocking our 8.5 and 9.0 OVS testing.

Do you have the updated policy or the workaround in place?
Was libvirt restarted afterwards?
Can you check the directory's SELinux type:

ls -Zal /run/libvirt/common/

(In reply to Zdenek Pytela from comment #18)
> (In reply to Jean-Tsung Hsiao from comment #17)
> > Our beaker tests failed due to this issue.
> > 
> > Below is our manual test:
> > 
> > virsh # start mq-vhu-tunnel 
> > error: Failed to start domain 'mq-vhu-tunnel'
> > error: can't connect to virtlogd: Unable to open system token
> > /run/libvirt/common/system.token: Permission denied
> > 
> > This is now blocking our 8.5 and 9.0 OVS testing.
> 
> Do you have the updated policy or the workaround in place?
Is there any ?

> Was libvirt restarted afterwards?
> Can you check the directory's SELinux type:
> 
> ls -Zal /run/libvirt/common/

[root@wsfd-advnetlab10 ~]# ls -Zal /run/libvirt/common/
total 4
drwx------.  2 root root system_u:object_r:virt_var_run_t:s0  60 Jun 23 23:29 .
drwxr-xr-x. 12 root root system_u:object_r:virt_var_run_t:s0 360 Jun 23 23:31 ..
-rw-------.  1 root root system_u:object_r:virt_var_run_t:s0  32 Jun 23 23:29 system.token
[root@wsfd-advnetlab10 ~]#

(In reply to Jean-Tsung Hsiao from comment #19)
> (In reply to Zdenek Pytela from comment #18)
> > (In reply to Jean-Tsung Hsiao from comment #17)
> > > Our beaker tests failed due to this issue.
> > > 
> > > Below is our manual test:
> > > 
> > > virsh # start mq-vhu-tunnel 
> > > error: Failed to start domain 'mq-vhu-tunnel'
> > > error: can't connect to virtlogd: Unable to open system token
> > > /run/libvirt/common/system.token: Permission denied
> > > 
> > > This is now blocking our 8.5 and 9.0 OVS testing.
> > 
> > Do you have the updated policy or the workaround in place?
> Is there any ?
Yes, see 3c+š, or wait until the new package is available.

> 
> > Was libvirt restarted afterwards?
> > Can you check the directory's SELinux type:
> > 
> > ls -Zal /run/libvirt/common/
> 
> [root@wsfd-advnetlab10 ~]# ls -Zal /run/libvirt/common/
> total 4
> drwx------.  2 root root system_u:object_r:virt_var_run_t:s0  60 Jun 23
> 23:29 .
> drwxr-xr-x. 12 root root system_u:object_r:virt_var_run_t:s0 360 Jun 23
> 23:31 ..
> -rw-------.  1 root root system_u:object_r:virt_var_run_t:s0  32 Jun 23
> 23:29 system.token
> [root@wsfd-advnetlab10 ~]#
The new package or workaround has to be in place to support the new feature, and the common directory relabeled or recreated.

FEDORA-2021-3df7370a94 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3df7370a94

FEDORA-2021-3df7370a94 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3df7370a94`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3df7370a94

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-3df7370a94 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.