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 1180713 - libvirt is unable to access default storage pool in MLS
Summary: libvirt is unable to access default storage pool in MLS
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Jiri Jaburek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-09 19:00 UTC by Jiri Jaburek
Modified: 2015-03-05 10:48 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-3.13.1-22.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 10:48:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0458 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2015-03-05 15:17:00 UTC

Description Jiri Jaburek 2015-01-09 19:00:52 UTC 
Description of problem:

It seems that libvirtd wants to read(2) /var,

type=SYSCALL msg=audit(01/09/2015 15:37:05.692:4050306) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=0x7efefc001c70 a1=O_RDONLY|O_NOCTTY|O_NONBLOCK a2=0x7eff132f39c0 a3=0x3 items=0 ppid=1 pid=57877 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=libvirtd exe=/usr/sbin/libvirtd subj=system_u:system_r:virtd_t:s0-s15:c0.c1023 key=(null)
type=AVC msg=audit(01/09/2015 15:37:05.692:4050306) : avc:  denied  { read } for  pid=57877 comm=libvirtd name=/ dev="dm-4" ino=128 scontext=system_u:system_r:virtd_t:s0-s15:c0.c1023 tcontext=system_u:object_r:var_t:s0 tclass=dir

(128 inode is / of dm-4 mounted as /var)

Disabling enforcing mode reveals few more accesses to /media and /media/floppy (confirmed by ls -i):

type=SYSCALL msg=audit(01/09/2015 15:37:26.800:4050618) : arch=x86_64 syscall=open success=yes exit=23 a0=0x7f3910001c70 a1=O_RDONLY|O_NOCTTY|O_NONBLOCK a2=0x7f3927f529c0 a3=0x3 items=0 ppid=1 pid=58353 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=libvirtd exe=/usr/sbin/libvirtd subj=system_u:system_r:virtd_t:s0-s15:c0.c1023 key=(null)
type=AVC msg=audit(01/09/2015 15:37:26.800:4050618) : avc:  denied  { read } for  pid=58353 comm=libvirtd name=/ dev="dm-4" ino=128 scontext=system_u:system_r:virtd_t:s0-s15:c0.c1023 tcontext=system_u:object_r:var_t:s0 tclass=dir
--
type=SYSCALL msg=audit(01/09/2015 15:37:26.800:4050619) : arch=x86_64 syscall=open success=yes exit=23 a0=0x7f3910002de0 a1=O_RDONLY|O_NOCTTY|O_NONBLOCK a2=0x7f3927f529c0 a3=0x5 items=0 ppid=1 pid=58353 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=libvirtd exe=/usr/sbin/libvirtd subj=system_u:system_r:virtd_t:s0-s15:c0.c1023 key=(null)
type=AVC msg=audit(01/09/2015 15:37:26.800:4050619) : avc:  denied  { read } for  pid=58353 comm=libvirtd name=media dev="dm-0" ino=1610612882 scontext=system_u:system_r:virtd_t:s0-s15:c0.c1023 tcontext=system_u:object_r:mnt_t:s0 tclass=dir
--
type=SYSCALL msg=audit(01/09/2015 15:37:26.900:4050620) : arch=x86_64 syscall=open success=yes exit=23 a0=0x7f3908008e20 a1=O_RDONLY|O_NOCTTY|O_NONBLOCK a2=0x7f392674f9c0 a3=0x6 items=0 ppid=1 pid=58356 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=libvirtd exe=/usr/sbin/libvirtd subj=system_u:system_r:virtd_t:s0-s15:c0.c1023 key=(null)
type=AVC msg=audit(01/09/2015 15:37:26.900:4050620) : avc:  denied  { read } for  pid=58356 comm=libvirtd name=floppy dev="dm-0" ino=538364192 scontext=system_u:system_r:virtd_t:s0-s15:c0.c1023 tcontext=staff_u:object_r:mnt_t:s0 tclass=dir

audit2allow on these AVCs generates:

require {
        type virtd_t;
}

#============= virtd_t ==============
files_list_mnt(virtd_t)
files_list_var(virtd_t)

Building and loading this module makes the AVCs disappear, with ausearch showing no additional matches.

I'm honestly not sure if opening these directories is by design, though I guess it would make sense while searching for removable media. Adding libvirt-maint to CC just in case this is unexpected.


Version-Release number of selected component (if applicable):
selinux-policy-3.13.1-14.el7.noarch

How reproducible:
always

Steps to Reproduce:
1. ts=$(date +%H:%M:%S)
2. service libvirtd restart
3. ausearch -m avc -ts $ts

Additional info:
There might be more (possibly unrelated) issues as qemu-kvm failed due to mls constraint violation, I'll debug and file this separately if it turns out to be a bug.
Comment 2 Miroslav Grepl 2015-01-12 12:02:42 UTC 
Did you test it with the latest policy? It should be allowed by

fs_list_auto_mountpoints(virtd_t)

which we have in the policy.
Comment 3 Jiri Jaburek 2015-01-13 10:33:02 UTC 
(In reply to Miroslav Grepl from comment #2)
> Did you test it with the latest policy? It should be allowed by
> 
> fs_list_auto_mountpoints(virtd_t)
> 
> which we have in the policy.

As written in comment #0, I tested this on selinux-policy-3.13.1-14.el7.noarch, which was latest at the time (latest releng tree + auto-updated rpm from erratum).

Can you please confirm that the fix is in later releases, as re-testing this bug requires nontrivial effort? I don't see anything related mentioned in later changelogs.

Thanks,
Jiri
Comment 9 Miroslav Grepl 2015-01-27 09:44:05 UTC 
commit e43df4fc0005e3238019c2e3c90bf143c07ea843
Author: Miroslav Grepl <mgrepl>
Date:   Mon Jan 26 16:09:12 2015 +0100

    Allow virtd to list all mountpoints.
Comment 17 errata-xmlrpc 2015-03-05 10:48:16 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://rhn.redhat.com/errata/RHBA-2015-0458.html
Note You need to log in before you can comment on or make changes to this bug.