Bug 1245756

Summary: SELinux is preventing abrt-hook-ccpp from using the 'sigchld' accesses on a process.
Product: [Fedora] Fedora Reporter: Jared Smith <jsmith.fedora>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: dominick.grift, dwalsh, jehan.marmottard, lvrabec, mgrepl, plautrba
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:ee92e20c4a93c317476200fdeccf54ce874f7a72ad896c30d2d4dc2941b12732
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-15 10:23:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output of `ps -efZ` none

Description Jared Smith 2015-07-22 16:39:24 UTC
Description of problem:
Unsuspended my laptop, and saw this alert.
SELinux is preventing abrt-hook-ccpp from using the 'sigchld' accesses on a process.

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

If you believe that abrt-hook-ccpp should be allowed sigchld access on processes labeled kernel_t 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 abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:NetworkManager_t:s0
Target Context                system_u:system_r:kernel_t:s0
Target Objects                Unknown [ process ]
Source                        abrt-hook-ccpp
Source Path                   abrt-hook-ccpp
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-128.6.fc22.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 4.1.2-200.fc22.x86_64 #1 SMP Wed
                              Jul 15 20:12:12 UTC 2015 x86_64 x86_64
Alert Count                   4
First Seen                    2015-07-21 13:20:59 EDT
Last Seen                     2015-07-21 13:22:03 EDT
Local ID                      279ce4ec-3409-40ba-a0bc-e945b800bc8a

Raw Audit Messages
type=AVC msg=audit(1437499323.704:878): avc:  denied  { sigchld } for  pid=17685 comm="abrt-hook-ccpp" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=0


Hash: abrt-hook-ccpp,NetworkManager_t,kernel_t,process,sigchld

Version-Release number of selected component:
selinux-policy-3.13.1-128.6.fc22.noarch

Additional info:
reporter:       libreport-2.6.1
hashmarkername: setroubleshoot
kernel:         4.1.2-200.fc22.x86_64
type:           libreport

Comment 1 Lukas Vrabec 2015-07-28 13:05:15 UTC
Hi, 
Please run and attach:
# ps -efZ 

Thank you

Comment 2 Jehan 2015-08-06 12:22:43 UTC
Created attachment 1059896 [details]
Output of `ps -efZ`

Hi,

I just had a similar SELinux alert preventing abrt-hook-cpp from accessing sigchld (many times in a row. I had the alert already 11 times in like 15 min).
The only diference is that Jared Smith's alert seem to originate from the network manager, and mine from the Mozilla flash plugin (v. 11.2.202.491 updated yesterday from Adobe website).

Below the alert details:

----------------------------------------------------------
SELinux is preventing abrt-hook-ccpp from using the sigchld access on a process.

*****  Plugin mozplugger (99.1 confidence) suggests   ************************

If you want to use the plugin package
Then you must turn off SELinux controls on the Firefox plugins.
Do
# setsebool -P unconfined_mozilla_plugin_transition 0

*****  Plugin catchall (1.81 confidence) suggests   **************************

If you believe that abrt-hook-ccpp should be allowed sigchld access on processes labeled kernel_t 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 abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c
                              0.c1023
Target Context                system_u:system_r:kernel_t:s0
Target Objects                Unknown [ process ]
Source                        abrt-hook-ccpp
Source Path                   abrt-hook-ccpp
Port                          <Unknown>
Host                          darkmarmot
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-128.8.fc22.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     darkmarmot
Platform                      Linux darkmarmot 4.1.3-200.fc22.x86_64 #1 SMP Wed
                              Jul 22 19:51:58 UTC 2015 x86_64 x86_64
Alert Count                   9
First Seen                    2015-08-06 13:56:26 CEST
Last Seen                     2015-08-06 14:08:40 CEST
Local ID                      da77c24a-0e3e-44a1-9b86-aee1492d7cd2

Raw Audit Messages
type=AVC msg=audit(1438862920.226:639): avc:  denied  { sigchld } for  pid=5332 comm="abrt-hook-ccpp" scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=0


Hash: abrt-hook-ccpp,mozilla_plugin_t,kernel_t,process,sigchld

----------------------------------------------------------

Attached is the output of `ps -efZ` which you were asking to the reporter (and where I saw that the mozilla_plugin refered in the alert is likely Flash, though PID are different, but it may just have respawned a different process).

Should these accesses be granted or is there a potential issue with Flash?

Comment 3 Miroslav Grepl 2015-08-15 10:23:14 UTC

*** This bug has been marked as a duplicate of bug 1245477 ***