Bug 1028600 - SELinux is preventing /usr/bin/python2.7 from 'read' accesses on the file unix.
SELinux is preventing /usr/bin/python2.7 from 'read' accesses on the file unix.
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-11-08 15:36 EST by liam
Modified: 2013-12-13 21:53 EST (History)
4 users (show)

See Also:
Fixed In Version: selinux-policy-3.12.1-105.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-13 21:53:25 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 liam 2013-11-08 15:36:51 EST
Description of problem:
SELinux is preventing /usr/bin/python2.7 from 'read' accesses on the file unix.

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

If you believe that python2.7 should be allowed read access on the unix file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
allow this access for now by executing:
# grep sealert /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:setroubleshoot_fixit_t:s0-s0:c0.
Target Context                system_u:object_r:proc_net_t:s0
Target Objects                unix [ file ]
Source                        sealert
Source Path                   /usr/bin/python2.7
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           python-2.7.5-8.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-90.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.11.7-300.fc20.x86_64 #1 SMP Mon
                              Nov 4 15:07:39 UTC 2013 x86_64 x86_64
Alert Count                   2
First Seen                    2013-11-08 15:30:37 EST
Last Seen                     2013-11-08 15:31:03 EST
Local ID                      3409b90c-07ef-4123-bc8f-21e2fefbd9b9

Raw Audit Messages
type=AVC msg=audit(1383942663.358:559): avc:  denied  { read } for  pid=2265 comm="sealert" name="unix" dev="proc" ino=4026532002 scontext=system_u:system_r:setroubleshoot_fixit_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_net_t:s0 tclass=file

type=SYSCALL msg=audit(1383942663.358:559): arch=x86_64 syscall=access success=no exit=EACCES a0=7fff3bc6c730 a1=4 a2=7fff3bc6c73e a3=a items=0 ppid=2264 pid=2265 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=sealert exe=/usr/bin/python2.7 subj=system_u:system_r:setroubleshoot_fixit_t:s0-s0:c0.c1023 key=(null)

Hash: sealert,setroubleshoot_fixit_t,proc_net_t,file,read

Additional info:
reporter:       libreport-2.1.9
hashmarkername: setroubleshoot
kernel:         3.11.7-300.fc20.x86_64
type:           libreport
Comment 1 liam 2013-11-08 15:48:31 EST
OK, this seems as though it's triggered by setroubleshoot. Specifically when attempting to perform a restorecon to an icc file colord needs access to.

SELinux is preventing /usr/libexec/colord from read access on the file /home/USERNAME/.local/share/icc/edid-ae2f7d53a85ccf03c8480cbaeae7bee0.icc.

*****  Plugin restorecon (82.4 confidence) suggests   ************************

If you want to fix the label. 
/home/USERNAME/.local/share/icc/edid-ae2f7d53a85ccf03c8480cbaeae7bee0.icc default label should be icc_data_home_t.
Then you can run restorecon.
# /sbin/restorecon -v /home/liemily/.local/share/icc/edid-ae2f7d53a85ccf03c8480cbaeae7bee0.icc
Comment 2 liam 2013-11-08 16:13:41 EST
OK,I guess there are two problems here. The first is that colord should be able to read the icc file, so that file should have been labeled differently (this might have arisen if selinux policy changed the labels for colord/icc access between F18 and F20 (I just updated but kept my /home intact).
The other problem is that the solution suggested by setroubleshoot requires the checkpolicy package which wasn't installed. 
So, perhaps, a dependency was overlooked for F20?
Comment 3 Daniel Walsh 2013-11-11 15:47:32 EST
Run restorecon -R -v /home

On your homedir.

a187ce2ad52bce0716f65e0c8731586f51a47182 fixes the setrouleshoot_fixit_t problem in git.
Comment 4 Fedora Update System 2013-11-27 03:14:32 EST
selinux-policy-3.12.1-105.fc20 has been submitted as an update for Fedora 20.
Comment 5 Fedora Update System 2013-11-27 11:12:25 EST
Package selinux-policy-3.12.1-105.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-105.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 6 Fedora Update System 2013-12-13 21:53:25 EST
selinux-policy-3.12.1-105.fc20 has been pushed to the Fedora 20 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.