Bug 1964317 - SELinux is preventing virtlogd from 'read, append' accesses on the file system.token
Summary: SELinux is preventing virtlogd from 'read, append' accesses on the file syste...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 34
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs 1966842 1969209
TreeView+ depends on / blocked
 
Reported: 2021-05-25 08:12 UTC by Han Han
Modified: 2022-01-17 08:02 UTC (History)
22 users (show)

Fixed In Version: selinux-policy-34.12-1.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1966842 (view as bug list)
Environment:
Last Closed: 2021-06-30 03:15:42 UTC
Type: Bug


Attachments (Terms of Use)
VM xml (6.07 KB, text/plain)
2021-05-25 08:12 UTC, Han Han
no flags Details

Description Han Han 2021-05-25 08:12:54 UTC
Created attachment 1786762 [details]
VM xml

Description of problem:
As subject

Version-Release number of selected component (if applicable):
libvirt since commit cbfebfc7
selinux-policy-targeted-3.14.6-37.fc33.noarch

How reproducible:
100%

Steps to Reproduce:
1. Build libvirt rpm from libvirt source code:
1.1 Dowloand libvirt source code
# git clone https://gitlab.com/libvirt/libvirt

1.2 Install build dependencies
# dnf builddep libvirt -y

1.3 Build&install libvirt rpms
# cd libvirt
# meson build
# cd build
# meson dist
# cp meson-dist/libvirt-*.tar.xz ~/rpmbuild/SOURCES
# cp libvirt.spec ~/rpmbuild/SPECS
# rpmbuild -ba ~/rpmbuild/SPECS/libvirt.spec
# dnf install ~/rpmbuild/RPMS/x86_64/libvirt* -y

2. Prepare an VM xml. Try to start the VM(see xml example in the attachment)
# virsh create hhan.xml
error: Failed to create domain from /tmp/hhan.xml
error: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied


avc deny message in sealert
➜  ~ sealert -a /var/log/audit/audit.log                                                           
100% done                     
found 1 alerts in /var/log/audit/audit.log                                                     
--------------------------------------------------------------------------------
                                               
SELinux is preventing virtlogd from 'read, append' accesses on the file system.token.
                                               
*****  Plugin catchall (100. confidence) suggests   **************************
                                                                                               
If you believe that virtlogd should be allowed read append access on the system.token file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do                                                                                             
allow this access for now by executing:                                                        
# ausearch -c 'virtlogd' --raw | audit2allow -M my-virtlogd
# semodule -X 300 -i my-virtlogd.pp
                                                                                                                                                                                                                                                                                             
Additional Information:
Source Context                system_u:system_r:virtlogd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:virt_var_run_t:s0
Target Objects                system.token [ file ]
Source                        virtlogd
Source Path                   virtlogd
Port                          <Unknown>
Host                          <Unknown>
Source RPM Packages           
Target RPM Packages                     
SELinux Policy RPM            selinux-policy-targeted-3.14.6-37.fc33.noarch
Local Policy RPM              selinux-policy-targeted-3.14.6-37.fc33.noarch                                                                                                                   
Selinux Enabled               True
Policy Type                   targeted                                                                                                                                                        
Enforcing Mode                Enforcing
Host Name                     hhan-fedora
Platform                      Linux hhan-fedora 5.12.6-200.fc33.x86_64 #1 SMP
                              Sat May 22 20:43:23 UTC 2021 x86_64 x86_64
Alert Count                   11
First Seen                    2021-05-19 06:59:51 UTC
Last Seen                     2021-05-25 07:52:08 UTC
Local ID                      78bfa111-99c9-4ca7-8a92-01e857b79691

Raw Audit Messages
type=AVC msg=audit(1621929128.410:299): avc:  denied  { read append } for  pid=1257 comm="virtlogd" name="system.token" dev="tmpfs" ino=1026 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1
023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=0                      


Hash: virtlogd,virtlogd_t,virt_var_run_t,file,read,append


Actual results:
As above

Expected results:
No avc deny

Additional info:
Reproduced on selinux-policy-34.7-1.fc35.noarch. Not reproduced on selinux-policy-targeted-3.14.3-68.el8.noarch

Comment 1 Zdenek Pytela 2021-05-26 14:51:59 UTC
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?

Comment 2 Zdenek Pytela 2021-05-26 14:54:29 UTC
I am sorry, I haven't noticed this reference /run/libvirt/common/system.token, so the path is known.

Comment 3 Daniel Berrangé 2021-05-26 14:59:26 UTC
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.

Comment 4 Zdenek Pytela 2021-05-26 15:24:39 UTC
Niki,

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

Comment 5 Han Han 2021-05-27 02:07:09 UTC
(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.

Comment 6 Andrea Bolognani 2021-06-04 13:48:05 UTC
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.

Comment 7 Zdenek Pytela 2021-06-07 16:36:24 UTC
> 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)

Comment 8 Daniel Berrangé 2021-06-07 16:47:53 UTC
(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.

Comment 9 Zdenek Pytela 2021-06-09 08:59:47 UTC
(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 }

Comment 10 Daniel Berrangé 2021-06-09 09:10:35 UTC
(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.

Comment 11 Zdenek Pytela 2021-06-09 12:41:23 UTC
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

Comment 12 Zdenek Pytela 2021-06-11 21:20:23 UTC
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

Comment 13 Zdenek Pytela 2021-06-14 06:38:58 UTC
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

Comment 14 Han Han 2021-06-15 03:56:00 UTC
(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

Comment 15 Zdenek Pytela 2021-06-15 06:56:01 UTC
(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.

Comment 16 Han Han 2021-06-15 07:19:04 UTC
(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

Comment 17 Jean-Tsung Hsiao 2021-06-22 19:56:55 UTC
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.

Comment 18 Zdenek Pytela 2021-06-23 07:53:47 UTC
(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/

Comment 19 Jean-Tsung Hsiao 2021-06-24 14:49:48 UTC
(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 ~]#

Comment 20 Zdenek Pytela 2021-06-24 15:21:45 UTC
(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.

Comment 21 Fedora Update System 2021-06-24 15:28:12 UTC
FEDORA-2021-3df7370a94 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3df7370a94

Comment 22 Fedora Update System 2021-06-24 16:55:54 UTC
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.

Comment 23 Fedora Update System 2021-06-30 03:15:42 UTC
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.

Comment 24 John L Magee 2021-08-01 13:37:12 UTC
Please provide a Fedora 33 selinux update so testing may proceed with virt-preview


Note You need to log in before you can comment on or make changes to this bug.