Description of problem: SELinux is preventing gdb from using the 'ptrace' accesses on a process. ***** Plugin catchall (100. confidence) suggests ************************** If jeśli gdb powinno mieć domyślnie ptrace dostęp do procesów z etykietami svirt_t. Then proszę to zgłosić jako błąd. Można utworzyć lokalny moduł polityki, aby umożliwić ten dostęp. Do można tymczasowo zezwolić na ten dostęp wykonując polecenia: # grep gdb /var/log/audit/audit.log | audit2allow -M mojapolityka # semodule -i mojapolityka.pp Additional Information: Source Context unconfined_u:unconfined_r:svirt_t:s0:c26,c396 Target Context unconfined_u:unconfined_r:svirt_t:s0:c26,c396 Target Objects Unknown [ process ] Source gdb Source Path gdb Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-155.fc23.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-12-06 00:24:02 CET Last Seen 2015-12-06 00:24:02 CET Local ID c68f8a55-93d4-4b8e-961d-95858fb1d9b6 Raw Audit Messages type=AVC msg=audit(1449357842.537:999): avc: denied { ptrace } for pid=18023 comm="gdb" scontext=unconfined_u:unconfined_r:svirt_t:s0:c26,c396 tcontext=unconfined_u:unconfined_r:svirt_t:s0:c26,c396 tclass=process permissive=0 Hash: gdb,svirt_t,svirt_t,process,ptrace Version-Release number of selected component: selinux-policy-3.13.1-155.fc23.noarch Additional info: reporter: libreport-2.6.3 hashmarkername: setroubleshoot kernel: 4.2.6-301.fc23.x86_64 type: libreport Potential duplicate: bug 883556
Why does qemu exec gdb? running gdb within a confined domain like this is often going to be blocked, because we don't want to allow confined domains to ptrace each other by default. If you had multiple processes running in this domain they would be able to look at each others memory. I think the problem here is some tool (Kernel? abrt?) is executing gdb when an application crashes and this process runs with the same label as the process that crashed. Is there a way that we could get gdb to run with a different type then we would not need to grant this access to the process type.
How did you start your virtual machine? gnome-boxes? virt-manager?
I see this behaviour on Rawhide with both gnome-boxes and virt-manager. virt-manager: type=AVC msg=audit(1452095504.334:735): avc: denied { ptrace } for pid=6049 comm="gdb" scontext=unconfined_u:unconfined_r:svirt_t:s0:c425,c647 tcontext=unconfined_u:unconfined_r:svirt_t:s0:c425,c647 tclass=process permissive=0 gnome-boxes: type=AVC msg=audit(1452095631.607:758): avc: denied { ptrace } for pid=6229 comm="gdb" scontext=unconfined_u:unconfined_r:svirt_t:s0:c141,c441 tcontext=unconfined_u:unconfined_r:svirt_t:s0:c141,c441 tclass=process permissive=0 I get an error from gnome-boxes (and the virt-manager error is similar): (gnome-boxes:6138): Boxes-WARNING **: machine.vala:607: Failed to start RHEL 7: Unable to start domain: internal error: process exited while connecting to monitor: ((null):6208): Spice-ERROR **: reds.c:3303:do_spice_init: statistics shm_open failed, Permission denied The earliest failure that I have in audit.log can be traced back to the 30th November, which seems to correspond to some shm changes in selinux-policy (but I am just guiessing, as I don't have much experience with SELinux troubleshooting): http://pkgs.fedoraproject.org/cgit/rpms/selinux-policy.git/commit/?id=0e84535c7a241fc32f4b904f019c807843dbb1a4
This is another case where an application is executing gdb under its domain. DId this happen on a KDE machine?
I see this under GNOME.
Do the qemu guys know who launched gdb on a crash?
Probably another case of https://bugzilla.redhat.com/show_bug.cgi?id=1021795#c8 I tried to hit this issue on f23 since I was considering just getting rid of this fromo spice but could not reproduce, so I assumed it might be fixed..
Yes, the question though is who is launching gdb?
QEMU (through libspice-server.so) ends up calling spice_backtrace(), which fork/exec /usr/bin/gstack, which is a script which launches gdb http://cgit.freedesktop.org/spice/spice-common/tree/common/backtrace.c#n60 I don't know if this is what is happening here, but this is one way gdb can be launched from QEMU.
Ok, that solves this one. (I see other random ones.) The question then is whether or not breaking gdb to prevent a process from looking at another processes with the same label memory is worth it. I think in this case we should probably allow this. Not a hacked svirt_t would still be blocked from ptracing another svirt_t if they had different MCS labels, which means one qemu could not look at the memory of a different qemu if they have different labels.
It makes sense.
selinux-policy-3.13.1-158.4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-2aa7777f21
selinux-policy-3.13.1-158.4.fc23 has been pushed to the Fedora 23 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-2016-2aa7777f21
selinux-policy-3.13.1-158.4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.