Bug 1598426
| Summary: | [OSP14] [standalone openstack] cannot launch instance with enable selinux for all-in-one installation - libvirt: error : cannot execute binary /usr/libexec/qemu-kvm: Permission denied | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Artem Hrechanychenko <ahrechan> | ||||||
| Component: | openstack-containers | Assignee: | Dan Prince <dprince> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Omri Hochman <ohochman> | ||||||
| Severity: | high | Docs Contact: | Andrew Burden <aburden> | ||||||
| Priority: | high | ||||||||
| Version: | 14.0 (Rocky) | CC: | ahrechan, aschultz, dbecker, jdenemar, kchamart, lhh, m.andre, mbooth, mburns, mgrepl, mmalik, morazi, rbalakri | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | DFG:DF | ||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2018-07-13 14:44:32 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Artem Hrechanychenko
2018-07-05 12:33:16 UTC
Created attachment 1456761 [details]
/var/log/containers
Please could you provide the audit logs containing the AVC denial. Also, is this reproducible without patches? The patches are necessary to run this setup (cloud in a single node). This is the expected configuration for OSP14 for this feature. Will try and grab the avc logs type=AVC msg=audit(1531151277.699:5956): avc: denied { entrypoint } for pid=166360 comm="libvirtd" path="/usr/libexec/qemu-kvm" dev="vda1" ino=80176023 scontext=system_u:system_r:svirt_tcg_t:s0:c115,c193 tcontext=system_u:object_r:container_share_t:s0 tclass=file
Created attachment 1457519 [details]
audit.log
(In reply to Alex Schultz from comment #5) > type=AVC msg=audit(1531151277.699:5956): avc: denied { entrypoint } for > pid=166360 comm="libvirtd" path="/usr/libexec/qemu-kvm" dev="vda1" > ino=80176023 scontext=system_u:system_r:svirt_tcg_t:s0:c115,c193 > tcontext=system_u:object_r:container_share_t:s0 tclass=file Unless it's being mislabeled, looks like you might be running TCG. Is this nested virt by any chance? You might want to check that it's correctly enabled. https://docs.fedoraproject.org/quick-docs/en-US/using-nested-virtualization-in-kvm.html This looks like an private matter between libvirt, qemu, and their SELinux policy. I suspect you've stumbled down an unsupported (and little tested) code path, and fixing nested virt will make it go away. Looking at openstack-selinux, I don't think this can be an issue in our policy customisations because we don't define either the type or the transition. I'm going to punt this to libvirt to either fix or signpost appropriately. The system_u:object_r:container_share_t context of /usr/libexec/qemu-kvm is incorrect, normally it is system_u:object_r:qemu_exec_t:s0. Moving back to OpenStack (openstack-containers looks like it could be the right component) since this has nothing to do with libvirt. (In reply to Matthew Booth from comment #7) > (In reply to Alex Schultz from comment #5) > > type=AVC msg=audit(1531151277.699:5956): avc: denied { entrypoint } for > > pid=166360 comm="libvirtd" path="/usr/libexec/qemu-kvm" dev="vda1" > > ino=80176023 scontext=system_u:system_r:svirt_tcg_t:s0:c115,c193 > > tcontext=system_u:object_r:container_share_t:s0 tclass=file > > Unless it's being mislabeled, looks like you might be running TCG. Is this > nested virt by any chance? You might want to check that it's correctly > enabled. Yes, they are using TCG, from that SELinux context. And this bug is eerily similar to this other one (which is now moved to 'selinux-policy' component: https://bugzilla.redhat.com/show_bug.cgi?id=1538651 ("When using --libvirttype qemu to deploy an overcloud, VMs can't be launched because SELinux blocks it") And the fix (not yet merged in 'selinux-policy' package) is outlined here: https://bugzilla.redhat.com/show_bug.cgi?id=1538651#c12 Agree with Jiri Denemark, the correct label for /usr/libexec/qemu-kvm is:
# matchpathcon /usr/libexec/qemu-kvm
/usr/libexec/qemu-kvm system_u:object_r:qemu_exec_t:s0
#
And SELinux policy defines following entrypoint rule:
# sesearch -s svirt_tcg_t -p entrypoint -A
Found 1 semantic av rules:
allow svirt_tcg_t qemu_exec_t : file { ioctl read getattr lock map execute entrypoint open } ;
#
Please run "restorecon -v /usr/libexec/qemu-kvm" to correct the label.
Kashyap seems to have found the older issue. Looking in openstack-selinux we do indeed already have:
allow svirt_t container_share_t:file { entrypoint execute };
We probably want to replicate a bunch of svirt_t rules for svirt_tcg_t. Although as mentioned earlier I don't believe we actually support TCG, but we prefer that it works.
*** This bug has been marked as a duplicate of bug 1538651 ***
|