Bug 1758640

Summary: upstream qemu change that mmaps ELF files breaks with selinux rules
Product: Red Hat Enterprise Linux 7 Reporter: Paolo Bonzini <pbonzini>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED WONTFIX QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.8CC: berrange, borntraeger, dhildenb, dwalsh, extras-qa, knoel, lvrabec, mgrepl, mmalik, pbonzini, plautrba, sgarzare, ssekidde, thuth, vmojzis, zpytela
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1758525 Environment:
Last Closed: 2019-12-09 14:26:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1758525    
Bug Blocks:    

Description Paolo Bonzini 2019-10-04 16:42:46 UTC
+++ This bug was initially created as a clone of Bug #1758525 +++

Description of problem:
Newer qemu git versions that contain 

commit 816b9fe450220e19acb91a0ce4a8ade7000648d1 (refs/bisect/bad)
    elf-ops.h: Map into memory the ELF to load

crash when an elf file is used as os.kernel:

2019-10-04T12:00:32.675188Z qemu-system-s390x: GLib: g_mapped_file_unref: assertion 'file != NULL' failed


strace tells that I can read the ELF file, but not mmap
strace:
214365 openat(AT_FDCWD, "/var/lib/libvirt/images/test_cpu_timer.elf", O_RDONLY) 
214365 read(46, "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0", 16) = 16
214365 lseek(46, 0, SEEK_SET)           = 0
[...]
214365 fstat(46, {st_mode=S_IFREG|0755, st_size=168176, ...}) = 0
214365 mmap(NULL, 168176, PROT_READ|PROT_WRITE, MAP_PRIVATE, 46, 0) = -1 EACCES (Permission denied)

So reading from /var/lib/libvirt/images/test_cpu_timer.elf does work, mmaping does not.
setenforce 0 makes the problem go away. 


audit2allow shows among others. 

allow svirt_t virt_content_t:file map;

--- Additional comment from Christian Borntraeger on 2019-10-04 12:46:36 UTC ---

Adding Daniel and Paolo as this was discussed on libvirt and qemu mailing list

https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg01122.html
https://www.redhat.com/archives/libvir-list/2019-October/msg00191.html

--- Additional comment from Daniel Berrangé on 2019-10-04 12:51:05 UTC ---

The virt.te policy rules already include:

  allow svirt_t svirt_image_t:file map;
  allow svirt_t svirt_image_t:blk_file map;


which handles disks/images we expose to QMEU with read-write permission.

virt_content_t is used for disk/images we expose to QEMU with read-only permission, and I don't see a reason why we can't allow mmap for those too. IIUC, we're enforcing read-only-ness of the file separately from the map permission.

So I think we probably want two additions:

  allow svirt_t virt_content_t:file map;
  allow svirt_t virt_content_t:blk_file map;

--- Additional comment from Christian Borntraeger on 2019-10-04 13:03:21 UTC ---

I guess this is also broken for RHEL,RHV. So as soon as qemu >= 4.2 is part of RHV, we have the same problem there as well.
Is there a process to cascade this into those distributions as well?

--- Additional comment from Lukas Vrabec on 2019-10-04 15:37:29 UTC ---

commit 76616cf62cddda3c6ca0a9cd1b7820052b228854 (HEAD -> rawhide)
Author: Lukas Vrabec <lvrabec>
Date:   Fri Oct 4 17:36:42 2019 +0200

    Update virt_read_content interface to allow caller domain mmap virt_content_t block devices and files
    
    Resolves: rhbz#1758525

Comment 5 Lukas Vrabec 2019-12-09 14:26:00 UTC
This issue was not selected to be included in Red Hat Enterprise Linux 7 because it is seen either as low or moderate impact to a small number of use-cases. Current minor release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.

We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.