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 1714896 - incomplete policy for libvirt daemons
Summary: incomplete policy for libvirt daemons
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.6
Hardware: All
OS: Linux
medium
low
Target Milestone: rc
: 7.8
Assignee: Lukas Vrabec
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 1733185
TreeView+ depends on / blocked
 
Reported: 2019-05-29 06:40 UTC by Doran Moppert
Modified: 2020-03-31 19:11 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-3.13.1-255.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1733185 (view as bug list)
Environment:
Last Closed: 2020-03-31 19:10:50 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:1007 0 None None None 2020-03-31 19:11:18 UTC

Description Doran Moppert 2019-05-29 06:40:10 UTC 
In bug 1706067, it looked like selinux was preventing exploitation of a libvirt CVE but further investigation showed some problems with the confinement leading to an easy bypass.

Two issues:
 - virtlockd should run in a confined context more similar to virtlogd_t than virtd_t
 - the virtlogd_t context probably needs much less filesystem access than it has

Quoting bug 1706067 comment 12:
In reply to comment #12:
> In reply to comment #4:
> > SELinux context for the virtlogd process prevents it reading the client's
> > /proc/X/stat entry
> 
> To be more specific, the full AVC denial message is:
> 
> > type=AVC msg=audit(1557278958.370:7143): avc:  denied  { search } for  pid=27744 comm="virtlogd" name="24609" dev="proc" ino=31260969 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=dir permissive=0
> > 
> > type=SYSCALL msg=audit(1557278958.370:7143): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffff9c a1=7f7b60003870 a2=0 a3=0 items=0 ppid=1 pid=27744 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=virtlogd exe=/usr/sbin/virtlogd subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null)
> 
> This is triggered by the openat() call from the chain
> virNetSocketGetUNIXIdentity() -> virProcessGetStartTime() ->
> virFileReadAll("/proc/24609/stat"), which comes after the SO_PEERCRED call
> succeeds.
> 
> Indeed, `virt-admin -c virtlogd:///system` triggers the same AVC failure
> even when run as root, when SELinux is enforcing.
> 
> By contrast, virtlockd is running under a different context:
> 
> > system_u:system_r:virtlogd_t:s0-s0:c0.c1023 root 1186 0.0  0.5 346760 10816 ?  Ss   21:39   0:00 /usr/sbin/virtlogd
> > system_u:system_r:virtd_t:s0-s0:c0.c1023 root 1250 0.0  0.6 365444 11436 ?     Ss   21:41   0:00 /usr/sbin/virtlockd
> 
> It appears that virtd_t has no such restrictions, so
> virNetSocketGetUNIXIdentity() succeeds completely when a user runs
> `virt-admin -c virtlockd:///system`, and further dangerous commands can
> invoked from there.
Comment 7 Lukas Vrabec 2019-08-06 15:30:44 UTC 
commit 42bef24fb6fc520a1338424fe3f57d3e116d673a (HEAD -> rhel7.8-contrib, origin/rhel7.8-contrib)
Author: Lukas Vrabec <lvrabec>
Date:   Thu Jul 25 12:44:52 2019 +0200

    Allow virtlockd process read virtlockd.conf file
    
    virtlockd process runs with virtlogd_t domain instead of vird_t domain,
    but virtlogd_t domain cannot acces virtlockd.conf files labeled as
    virt_etc_t. This commit fixes the issue
    Resolves: rhbz#1714896
Comment 16 errata-xmlrpc 2020-03-31 19:10:50 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, 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-2020:1007
Note You need to log in before you can comment on or make changes to this bug.