This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1021795 - spice wants to run 'gstack' on itself to log backtrace, upsets selinux
spice wants to run 'gstack' on itself to log backtrace, upsets selinux
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: spice (Show other bugs)
25
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Christophe Fergeau
Fedora Extras Quality Assurance
abrt_hash:54b3f0b26c809c29e55b14da243...
: Reopened
: 1266582 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-22 02:33 EDT by Adam Williamson
Modified: 2016-12-13 09:05 EST (History)
25 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-12 15:49:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2013-10-22 02:33:25 EDT
Description of problem:
Well, no idea really, but I'd just tried to run rendercheck in a VM, and things seemed to go south.
SELinux is preventing /usr/bin/gdb from 'open' accesses on the file /var/lib/rpm/Packages.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that gdb should be allowed open access on the Packages 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:
# grep gdb /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:svirt_t:s0:c547,c920
Target Context                system_u:object_r:rpm_var_lib_t:s0
Target Objects                /var/lib/rpm/Packages [ file ]
Source                        gdb
Source Path                   /usr/bin/gdb
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           gdb-7.6.50.20130731-12.fc20.x86_64
Target RPM Packages           rpm-4.11.1-7.fc20.x86_64
Policy RPM                    selinux-policy-3.12.1-90.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 3.11.6-300.fc20.x86_64 #1 SMP Fri
                              Oct 18 22:31:53 UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-10-21 23:32:06 PDT
Last Seen                     2013-10-21 23:32:06 PDT
Local ID                      e03def73-ecd2-4e00-bf7b-495c06672b4b

Raw Audit Messages
type=AVC msg=audit(1382423526.567:1667): avc:  denied  { open } for  pid=19890 comm="gdb" path="/var/lib/rpm/Packages" dev="dm-1" ino=686712 scontext=system_u:system_r:svirt_t:s0:c547,c920 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file


type=SYSCALL msg=audit(1382423526.567:1667): arch=x86_64 syscall=open success=yes exit=ENOMEM a0=23c0b90 a1=0 a2=0 a3=7fff6f7f04c0 items=0 ppid=19886 pid=19890 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 ses=4294967295 tty=(none) comm=gdb exe=/usr/bin/gdb subj=system_u:system_r:svirt_t:s0:c547,c920 key=(null)

Hash: gdb,svirt_t,rpm_var_lib_t,file,open

Additional info:
reporter:       libreport-2.1.8
hashmarkername: setroubleshoot
kernel:         3.11.6-300.fc20.x86_64
type:           libreport
Comment 1 Daniel Walsh 2013-10-22 13:32:08 EDT
Looks like a crashing svirt_t process is trying to launch gdb which is not something we will support from a svirt confinement.

This is most likely not the cause of everything going south, but the result.
Comment 2 Cole Robinson 2013-10-31 16:32:44 EDT
I don't understand where this is coming from, libvirt or qemu don't appear to launch gdb anywhere. Not really sure what to do with this one, someone reopen if they have hints
Comment 3 Daniel Walsh 2013-11-01 12:33:09 EDT
Could this be abrt doing something wacky?
Comment 4 Jakub Filak 2013-11-01 15:58:27 EDT
abrt uses gdb to create a backtrace and explore vulnerabilities. However abrt does this for all detected coredumps.


abrt vulnerability analysis snippet:

gdb --batch \
    -ex 'python execfile("/usr/libexec/abrt-gdb-exploitable")' \
    -ex 'core-file ./coredump' \
    -ex 'abrt-exploitable 4 ./exploitable'
Comment 5 Daniel Walsh 2013-11-04 10:51:01 EST
Jakub does it do this by inserting a library into the process stack?  We do not want to allow every app on the system to be allowed to execute gdb and ptrace processes.
Comment 6 Jakub Filak 2013-11-04 11:14:05 EST
(In reply to Daniel Walsh from comment #5)
I am not sure if this will answer your question exactly but abrt always runs gdb on a core dump file stored in /var/tmp/abrt/ccpp-* directory (abrt never tries to attach a running process) and all gdb processes are run by one of the following executables /usr/sbin/abrtd, /usr/bin/abrt-action-generate-core-backtrace and /usr/bin/abrt-action-analyze-vulnerability.
Comment 7 Daniel Walsh 2013-11-04 12:31:34 EST
Which probably means these are not being caused by abrt.  But by something else?

What desktop are you guys running? kde?
Comment 8 Cole Robinson 2013-12-17 16:18:50 EST
I just hit this myself. Looks like spice has some internal 'log a backtrace' behavior that basically just calls 'gstack' on the current process. Not surprising that selinux complains.

spice guys, can there be a configure switch that disables this behavior that we turn on by default in fedora? abrt is going to catch these backtraces anyways so there's not much gained from dumping them in the libvirt logs.
Comment 9 Fedora Admin XMLRPC Client 2014-03-17 05:25:49 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Fedora End Of Life 2015-05-29 05:36:38 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 11 Cole Robinson 2015-05-31 15:03:54 EDT
Haven't seen any other selinux warnings about this, so I assume this was fixed somehow
Comment 12 Cole Robinson 2016-03-17 11:10:52 EDT
*** Bug 1266582 has been marked as a duplicate of this bug. ***
Comment 13 Cole Robinson 2016-03-17 11:11:56 EDT
There were hits on f23, I suspect this is still relevant
Comment 14 Fedora End Of Life 2016-11-24 06:03:30 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 15 Cole Robinson 2016-12-12 15:49:45 EST
I can't find any reference to backtracing in the latest spice.git code, nor any recent selinux AVC reports in bugzilla, so hopefully this is fixed/avoided nowadays
Comment 16 Christophe Fergeau 2016-12-13 04:51:40 EST
For what it's worth, spice still has this code, it's in a git submodule:
https://cgit.freedesktop.org/spice/spice-common/tree/common/log.c#n150
https://cgit.freedesktop.org/spice/spice-common/tree/common/backtrace.c

Iirc I did not manage to get selinux warnings last time I tried to reproduce.
Comment 17 Cole Robinson 2016-12-13 09:05:10 EST
Whoops, I tried to check spice-common but must have screwed it up somehow...

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