RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2002143 - SELinux label for file system.token is wrong if it is generated by virtproxyd
Summary: SELinux label for file system.token is wrong if it is generated by virtproxyd
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: selinux-policy
Version: 9.0
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: 9.0
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-09-08 05:11 UTC by Fangge Jin
Modified: 2022-05-17 16:11 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-34.1.17-1.el9
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-17 15:49:48 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1854332 1 None None None 2023-05-17 11:14:56 UTC
Red Hat Issue Tracker RHELPLAN-96491 0 None None None 2021-09-08 05:11:51 UTC
Red Hat Product Errata RHBA-2022:3918 0 None None None 2022-05-17 15:50:00 UTC

Description Fangge Jin 2021-09-08 05:11:22 UTC 
Description of problem:
Selinux lable for file system.token is wrong if it is generated by virtproxyd

Version-Release number of selected component:
libvirt-client-7.6.0-2.el9.x86_64
selinux-policy-34.1.14-1.el9.noarch

How reproducible:
100%

Steps to Reproduce:
1. Install libvirt freshly or remove dir /run/libvirt/common if exists

2. Enable modular daemon mode
systemctl disable libvirtd.service

systemctl disable libvirtd{,-ro,-admin,-tcp,-tls}.socket

systemctl enable virtlogd; systemctl enable virtlogd.socket; systemctl start virtlogd.socket

for drv in qemu interface network nodedev nwfilter secret storage proxy; do systemctl unmask virt${drv}d.service; systemctl unmask virt${drv}d{,-ro,-admin}.socket; systemctl enable virt${drv}d.service; systemctl enable virt${drv}d{,-ro,-admin}.socket; systemctl restart virt${drv}d{,-ro,-admin}.socket ; done 


3. Set auth_tcp=0 in virtproxyd.conf and start virtproxyd-tcp.socket

4. Connect to virtproxyd(virtlogd.service will be activated automatically): virsh -c qemu+tcp://10.73.178.89/system

5. Check system.token label:
# ll /run/libvirt/common/ -Z
total 4
-rw-------. 1 root root system_u:object_r:virt_var_run_t:s0 32 Sep  7 22:02 system.token

6. (restart virtlogd.service if it is active)
Try to define and start guest:
# virsh -c qemu+tcp://10.73.178.89/system define rhel8-temp.xml
Domain 'template' defined from rhel8-temp.xml

# virsh -c qemu+tcp://10.73.178.89/system start template
error: Failed to start domain 'template'
error: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied

Actual results:
As steps

Expected results:
The label should be:
# ll /run/libvirt/common/ -Z
total 4
-rw-------. 1 root root system_u:object_r:virt_common_var_run_t:s0 32 Sep  7 22:16 system.token


Additional info:
In step4, f connect to qemu driver directly without virtproxyd(virsh -c qemu:///system, virtqemud.service will be activated automatically), the label is correct.
Comment 1 Milos Malik 2021-09-16 09:29:35 UTC 
Caught in enforcing mode:
----
type=PROCTITLE msg=audit(09/16/2021 05:27:17.872:2290) : proctitle=/usr/sbin/virtlogd 
type=PATH msg=audit(09/16/2021 05:27:17.872:2290) : item=1 name=/run/libvirt/common/system.token inode=2815 dev=00:19 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(09/16/2021 05:27:17.872:2290) : item=0 name=/run/libvirt/common/ inode=2814 dev=00:19 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(09/16/2021 05:27:17.872:2290) : cwd=/ 
type=SYSCALL msg=audit(09/16/2021 05:27:17.872:2290) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x55c83cf5adb0 a2=O_RDWR|O_CREAT|O_APPEND a3=0x180 items=2 ppid=1 pid=10191 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(09/16/2021 05:27:17.872:2290) : avc:  denied  { read append } for  pid=10191 comm=virtlogd name=system.token dev="tmpfs" ino=2815 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 
----

# ls -dZ /run/libvirt/common/
system_u:object_r:virt_var_run_t:s0 /run/libvirt/common/
# matchpathcon /run/libvirt/common/
/run/libvirt/common	system_u:object_r:virt_common_var_run_t:s0
#
Comment 2 Milos Malik 2021-09-16 09:42:31 UTC 
# ps -efZ | grep virt
system_u:system_r:virtlogd_t:s0-s0:c0.c1023 root 7036  1  0 04:55 ?        00:00:00 /usr/sbin/virtlockd
system_u:system_r:virtlogd_t:s0-s0:c0.c1023 root 10191 1  0 05:26 ?        00:00:00 /usr/sbin/virtlogd
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 10234 3914  0 05:35 pts/0 00:00:00 grep --color=auto virt
# sesearch -s virtd_t -t virt_var_run_t -c dir -T
type_transition virtd_t virt_var_run_t:dir dnsmasq_var_run_t network;
type_transition virtd_t virt_var_run_t:dir qemu_var_run_t qemu;
type_transition virtd_t virt_var_run_t:dir virt_common_var_run_t common;
type_transition virtd_t virt_var_run_t:dir virt_lxc_var_run_t lxc;
# sesearch -s virtlogd_t -t virt_var_run_t -c dir -T
# 

Not sure which process created the /run/libvirt/common/ directory, but my guess is one of processes labeled virtlogd_t.
Comment 3 Milos Malik 2021-09-16 09:47:52 UTC 
# virsh -c qemu+tcp://<ip-address>/system start vmguest
error: Failed to start domain 'vmguest'
error: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied
#
Comment 5 Milos Malik 2021-09-16 09:52:06 UTC 
First part of this step does not work:

3. Set auth_tcp=0 in virtproxyd.conf and start virtproxyd-tcp.socket

It leads to the following message in the journal:

virtproxyd[10117]: 2021-09-16 09:22:57.840+0000: 10117: error : main:918 : Can't load config file: internal error: /etc/libvirt/virtproxyd.conf: expected a string for 'auth_tcp' parameter: /etc/libvirt/virtproxyd.conf

But setting auth_tcp = "none" works as expected.
Comment 6 Milos Malik 2021-09-16 09:58:51 UTC 
Because the virtproxyd program is not confined:

# ls -Z `which virtproxyd`
system_u:object_r:bin_t:s0 /usr/sbin/virtproxyd
# matchpathcon `which virtproxyd`
/usr/sbin/virtproxyd	system_u:object_r:bin_t:s0
#

the incorrectly labeled /run/libvirt/common directory could have been created by the virtproxyd process, because appropriate filename transition rule is missing:

# sesearch -s unconfined_service_t -t virt_var_run_t -c dir -T
#
Comment 7 Patrik Koncity 2021-09-30 12:14:52 UTC 
In https://bugzilla.redhat.com/show_bug.cgi?id=1854332 was solving confining virtproxyd. After adding this fix to policy should virtproxyd /usr/sbin/virtproxyd label as virtproxy_exec_t.
Comment 8 Zdenek Pytela 2021-10-11 14:33:26 UTC 
@Fangge Jin, I was unable to reproduce the scenario. Even when I install all packages referred to:

dnf install libvirt-client libvirt-daemon libvirt-daemon-driver-interface libvirt-daemon-driver-network libvirt-daemon-driver-nodedev libvirt-daemon-driver-nwfilter libvirt-daemon-driver-qemu libvirt-daemon-driver-secret libvirt-daemon-driver-storage-core

I get just:

# virsh -c qemu+tcp://10.0.139.141/system
error: failed to connect to the hypervisor
error: unable to connect to server at '10.0.139.141:16509': Connection refused
# systemctl status virtlogd
○ virtlogd.service - Virtual machine log manager
     Loaded: loaded (/usr/lib/systemd/system/virtlogd.service; indirect; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: ○ virtlogd.socket
             ○ virtlogd-admin.socket
       Docs: man:virtlogd(8)
             https://libvirt.org

Which steps are missing?

For sure we can start with backporting the existing commit (see #c7):
commit 9a1d09d6d42a5e450e721321e4c2d93fbea60423 (HEAD -> rawhide, upstream/rawhide)
Author: Patrik Koncity <pkoncity>
Date:   Thu Sep 2 15:51:12 2021 +0200

    Label /usr/sbin/virtproxyd as virtd_exec_t
Comment 9 Fangge Jin 2021-10-12 02:13:09 UTC 
@Zdenek Pktela, did you enable tcp socket:
Set auth_tcp="none" in /etc/libvirt/virtproxyd.conf and start virtproxyd-tcp.socket(systemctl start virtproxyd-tcp.socket)
Comment 10 Zdenek Pytela 2021-10-14 07:15:05 UTC 
I followed the instructions, still sometimes get errors I am unable to evaluate. Changing the virtproxyd label seems to help though.
Comment 20 errata-xmlrpc 2022-05-17 15:49:48 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: selinux-policy), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:3918
Note You need to log in before you can comment on or make changes to this bug.