Bug 1758545

+++ 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 13:46:36 BST ---

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 13:51:05 BST ---

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 14:03:21 BST ---

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?