Bug 1288776 - SELinux is preventing gdb from using the 'ptrace' accesses on a process.
SELinux is preventing gdb from using the 'ptrace' accesses on a process.
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Unspecified
medium Severity medium
: ---
: ---
Assigned To: Lukas Vrabec
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-12-05 18:31 EST by krzysztofbti
Modified: 2016-02-07 00:24 EST (History)
17 users (show)

See Also:
Fixed In Version: selinux-policy-3.13.1-158.4.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-02-07 00:24:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description krzysztofbti 2015-12-05 18:31:08 EST
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.
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:

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.2.6-301.fc23.x86_64
type:           libreport

Potential duplicate: bug 883556
Comment 1 Daniel Walsh 2015-12-09 14:41:15 EST
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.
Comment 2 Miroslav Grepl 2016-01-04 08:57:17 EST
How did you start your virtual machine? gnome-boxes? virt-manager?
Comment 3 David King 2016-01-06 11:10:34 EST
I see this behaviour on Rawhide with both gnome-boxes and 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

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):

Comment 4 Daniel Walsh 2016-01-07 09:10:46 EST
This is another case where an application is executing gdb under its domain.  DId this happen on a KDE machine?
Comment 5 David King 2016-01-07 09:15:29 EST
I see this under GNOME.
Comment 6 Daniel Walsh 2016-01-07 09:23:17 EST
Do the qemu guys know who launched gdb on a crash?
Comment 7 Christophe Fergeau 2016-01-07 10:15:33 EST
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..
Comment 8 Daniel Walsh 2016-01-07 17:17:15 EST
Yes, the question though is who is launching gdb?
Comment 9 Christophe Fergeau 2016-01-08 03:44:09 EST
QEMU (through libspice-server.so) ends up calling spice_backtrace(), which fork/exec /usr/bin/gstack, which is a script which launches gdb

I don't know if this is what is happening here, but this is one way gdb can be launched from QEMU.
Comment 10 Daniel Walsh 2016-01-08 08:24:11 EST
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.
Comment 11 Miroslav Grepl 2016-01-21 06:12:34 EST
It makes sense.
Comment 12 Fedora Update System 2016-02-03 07:02:07 EST
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
Comment 13 Fedora Update System 2016-02-03 18:00:06 EST
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
Comment 14 Fedora Update System 2016-02-07 00:23:38 EST
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.

Note You need to log in before you can comment on or make changes to this bug.