Description of problem: qemu 2.8.0 triggers this on shutdown. Seems to be due to this qemu commit. Not sure how to handle this from selinux perspective in a generic way, since we could be dealing with any label here. commit fbe7e3327a8cfa1b08664c2cda7a0a341cf0530a Author: Michal Privoznik <mprivozn> Date: Tue Sep 27 17:24:57 2016 +0200 qemu_kill_report: Report PID name too When qemu is being killed, its last words are: 2016-08-31T11:48:15.293587Z qemu-system-x86_64: terminating on signal 15 from pid 11180 That's nice, but what process is 11180? What if I told you we can do better: 2016-08-31T11:48:15.293587Z qemu-system-x86_64: terminating on signal 15 from pid 11180 (/usr/sbin/libvirtd) And that's exactly what this patch does. SELinux is preventing qemu-system-x86 from 'open' accesses on the file /proc/<pid>/cmdline. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that qemu-system-x86 should be allowed open access on the cmdline file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'qemu-system-x86' --raw | audit2allow -M my-qemusystemx86 # semodule -X 300 -i my-qemusystemx86.pp Additional Information: Source Context system_u:system_r:svirt_t:s0:c551,c1023 Target Context system_u:system_r:virtd_t:s0-s0:c0.c1023 Target Objects /proc/<pid>/cmdline [ file ] Source qemu-system-x86 Source Path qemu-system-x86 Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-225.3.fc25.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.8.14-300.fc25.x86_64 #1 SMP Mon Dec 12 16:31:04 UTC 2016 x86_64 x86_64 Alert Count 1 First Seen 2016-12-21 20:20:35 EST Last Seen 2016-12-21 20:20:35 EST Local ID 09ca515e-6b53-41d7-91ba-39de73123948 Raw Audit Messages type=AVC msg=audit(1482369635.38:965): avc: denied { open } for pid=4805 comm="qemu-system-x86" path="/proc/1024/cmdline" dev="proc" ino=22312 scontext=system_u:system_r:svirt_t:s0:c551,c1023 tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=file permissive=1 Hash: qemu-system-x86,svirt_t,virtd_t,file,open Version-Release number of selected component: selinux-policy-3.13.1-225.3.fc25.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.8.14-300.fc25.x86_64 type: libreport
Note this happens every time a VM is 'destroy'd by libvirt. Doesn't have any real effect but annoying since it pops up sealert. CCing Michal who implemented the qemu side of this. Anyone have an idea to avoid upsetting selinux here?
CCing Michal since he implemented the qemu side of this
(In reply to Cole Robinson from comment #2) > CCing Michal since he implemented the qemu side of this Cole, I think selinux policy can be made so that not certain label is allowed to read /proc/$pid/cmdline, but also a binary can be allowed to do the read. For instance qemu-system-x86_64 could read /proc/*/cmdline.
(In reply to Michal Privoznik from comment #3) > (In reply to Cole Robinson from comment #2) > > CCing Michal since he implemented the qemu side of this > > Cole, I think selinux policy can be made so that not certain label is > allowed to read /proc/$pid/cmdline, but also a binary can be allowed to do > the read. For instance qemu-system-x86_64 could read /proc/*/cmdline. lvrabec does that sound doable here?
ping, can we get a comment here from selinux guys?
Hi, SELinux denied this because virt machined was trying to read process information in /proc/<pid>/ directory. If we would like to allow this, we need to allow svirt_t (domain for virt machines) read all libvirtd process information in /proc/<pid>/* . I think it's good to isolate virt machine from host as much as possible. We have 2 options here how to fix it. 1. Allow virt machined read process information of libvirtd process. 2. Dontaudit this access. SELinux will deny it in future if will be in enforcing mode but there will be no AVC record about this action.
So there's no path based 'allow' rules like Michal suggests in Comment #3? If that exists it sounds like the best option to me If not, I agree that letting svirt_t open/read any virtd_t files is too much, so I'd go with the dontaudit. It completely kills the qemu debugging feature though so it would be ideal to find a better solution
Cole, Unfortunately, I cannot create allow rules which just allow reading /proc/<pid>/cmdline because all files in /proc/<pid>/ has same label. e.g.: $ ls -Z system_u:system_r:virtd_t:s0-s0:c0.c1023 attr system_u:system_r:virtd_t:s0-s0:c0.c1023 autogroup system_u:system_r:virtd_t:s0-s0:c0.c1023 auxv system_u:system_r:virtd_t:s0-s0:c0.c1023 cgroup system_u:system_r:virtd_t:s0-s0:c0.c1023 clear_refs system_u:system_r:virtd_t:s0-s0:c0.c1023 cmdline system_u:system_r:virtd_t:s0-s0:c0.c1023 comm system_u:system_r:virtd_t:s0-s0:c0.c1023 coredump_filter system_u:system_r:virtd_t:s0-s0:c0.c1023 cpuset system_u:system_r:virtd_t:s0-s0:c0.c1023 cwd system_u:system_r:virtd_t:s0-s0:c0.c1023 environ system_u:system_r:virtd_t:s0-s0:c0.c1023 exe system_u:system_r:virtd_t:s0-s0:c0.c1023 fd system_u:system_r:virtd_t:s0-s0:c0.c1023 fdinfo system_u:system_r:virtd_t:s0-s0:c0.c1023 gid_map system_u:system_r:virtd_t:s0-s0:c0.c1023 io system_u:system_r:virtd_t:s0-s0:c0.c1023 latency system_u:system_r:virtd_t:s0-s0:c0.c1023 limits system_u:system_r:virtd_t:s0-s0:c0.c1023 loginuid system_u:system_r:virtd_t:s0-s0:c0.c1023 map_files system_u:system_r:virtd_t:s0-s0:c0.c1023 maps system_u:system_r:virtd_t:s0-s0:c0.c1023 mem system_u:system_r:virtd_t:s0-s0:c0.c1023 mountinfo system_u:system_r:virtd_t:s0-s0:c0.c1023 mounts system_u:system_r:virtd_t:s0-s0:c0.c1023 mountstats system_u:system_r:virtd_t:s0-s0:c0.c1023 net system_u:system_r:virtd_t:s0-s0:c0.c1023 ns system_u:system_r:virtd_t:s0-s0:c0.c1023 numa_maps system_u:system_r:virtd_t:s0-s0:c0.c1023 oom_adj system_u:system_r:virtd_t:s0-s0:c0.c1023 oom_score system_u:system_r:virtd_t:s0-s0:c0.c1023 oom_score_adj system_u:system_r:virtd_t:s0-s0:c0.c1023 pagemap system_u:system_r:virtd_t:s0-s0:c0.c1023 personality system_u:system_r:virtd_t:s0-s0:c0.c1023 projid_map system_u:system_r:virtd_t:s0-s0:c0.c1023 root system_u:system_r:virtd_t:s0-s0:c0.c1023 sched system_u:system_r:virtd_t:s0-s0:c0.c1023 schedstat system_u:system_r:virtd_t:s0-s0:c0.c1023 sessionid system_u:system_r:virtd_t:s0-s0:c0.c1023 setgroups system_u:system_r:virtd_t:s0-s0:c0.c1023 smaps system_u:system_r:virtd_t:s0-s0:c0.c1023 stack system_u:system_r:virtd_t:s0-s0:c0.c1023 stat system_u:system_r:virtd_t:s0-s0:c0.c1023 statm system_u:system_r:virtd_t:s0-s0:c0.c1023 status system_u:system_r:virtd_t:s0-s0:c0.c1023 syscall system_u:system_r:virtd_t:s0-s0:c0.c1023 task system_u:system_r:virtd_t:s0-s0:c0.c1023 timers system_u:system_r:virtd_t:s0-s0:c0.c1023 timerslack_ns system_u:system_r:virtd_t:s0-s0:c0.c1023 uid_map system_u:system_r:virtd_t:s0-s0:c0.c1023 wchan We need to have different label for: system_u:system_r:virtd_t:s0-s0:c0.c1023 cmdline I'm for dontauditing.
selinux-policy-3.13.1-225.16.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9a20533d62
selinux-policy-3.13.1-225.16.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9a20533d62
selinux-policy-3.13.1-225.16.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.