Bug 678265 - SELinux is preventing /usr/bin/python from 'create' accesses on the directory .sandboxAfDuUv.
Summary: SELinux is preventing /usr/bin/python from 'create' accesses on the directory...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: policycoreutils
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:6d418b3a77e...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-17 10:54 UTC by Mads Kiilerich
Modified: 2012-12-06 19:54 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-06 19:54:56 UTC
Type: ---


Attachments (Terms of Use)

Description Mads Kiilerich 2011-02-17 10:54:44 UTC
SELinux is preventing /usr/bin/python from 'create' accesses on the directory .sandboxAfDuUv.

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

If you believe that python should be allowed create access on the .sandboxAfDuUv directory 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 sandbox /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:unconfined_t:s0
Target Context                unconfined_u:object_r:sandbox_web_file_t:s0:c131,c
                              513
Target Objects                .sandboxAfDuUv [ dir ]
Source                        sandbox
Source Path                   /usr/bin/python
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           python-2.7-8.fc14.1
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-29.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 2.6.35.11-83.fc14.i686.PAE #1 SMP Mon
                              Feb 7 06:57:55 UTC 2011 i686 i686
Alert Count                   1
First Seen                    Thu 17 Feb 2011 11:45:30 AM CET
Last Seen                     Thu 17 Feb 2011 11:45:30 AM CET
Local ID                      1d1d6bb0-935f-4e4d-8231-e91a37f0272a

Raw Audit Messages
type=AVC msg=audit(1297939530.867:17309): avc:  denied  { create } for  pid=29100 comm="sandbox" name=".sandboxAfDuUv" scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:object_r:sandbox_web_file_t:s0:c131,c513 tclass=dir


type=SYSCALL msg=audit(1297939530.867:17309): arch=i386 syscall=mkdir success=no exit=EACCES a0=93eeb90 a1=1c0 a2=74040cc a3=920b050 items=0 ppid=29086 pid=29100 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts2 ses=2 comm=sandbox exe=/usr/bin/python subj=unconfined_u:unconfined_r:unconfined_t:s0 key=(null)

Hash: sandbox,unconfined_t,sandbox_web_file_t,dir,create

audit2allow

#============= unconfined_t ==============
#!!!! This avc is a constraint violation.  You will need to add an attribute to either the source or target type to make it work.
#Contraint rule: 
allow unconfined_t sandbox_web_file_t:dir create;

audit2allow -R

#============= unconfined_t ==============
#!!!! This avc is a constraint violation.  You will need to add an attribute to either the source or target type to make it work.
#Contraint rule: 
allow unconfined_t sandbox_web_file_t:dir create;

Comment 1 Mads Kiilerich 2011-02-17 10:59:33 UTC
Sandbox worked for me 14 days ago (with updates-testing), but now I get this.

I guess it can have been caused by a full relabelling or SE updates.

The full error message is: 
$ sandbox -X -t sandbox_web_t firefox
/usr/bin/sandbox: [Errno 13] Permission denied: '/home/mk/.sandbox/.sandboxAfDuUv'

policycoreutils-python-2.0.83-33.10.fc14.i686

Comment 2 Daniel Walsh 2011-02-17 13:44:54 UTC
You login account is running as unconfined_t:s0 instead of unconfined_t:s0-s0:c0.c1023

Did you modify the seusers account?

semanage login -l

Comment 3 Mads Kiilerich 2011-02-17 14:28:10 UTC
Yes, that seems to be the problem.

[mk@dev-mk ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0

[root@dev-mk ~]# semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              s0                       
root                      unconfined_u              s0-s0:c0.c1023           
system_u                  system_u                  s0-s0:c0.c1023           
xguest                    xguest_u                  s0                       
[root@dev-mk ~]# ll /etc/selinux/targeted/seusers 
-rw-r--r--. 1 root root 183 Feb  7 11:29 /etc/selinux/targeted/seusers
[root@dev-mk ~]# cat /etc/selinux/targeted/seusers 
# This file is auto-generated by libsemanage
# Do not edit directly.

system_u:system_u:s0-s0:c0.c1023
root:unconfined_u:s0-s0:c0.c1023
__default__:unconfined_u:s0
xguest:xguest_u:s0

I reproduced on another machine and verified that this solved it:
[root@dev-mk ~]# semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 __default__ 
(not tested on this machine yet)


I am quite sure that I haven't modified the seusers account. It worked few days before the seusers file was touched. Can some other tool or updates-testing package have changed it?

The timestamp on seusers matches a policy installation, but I don't know if it touched the file for other good reasons:

Feb  7 11:27:28 dev-mk yum[19514]: Updated: selinux-policy-3.9.7-29.fc14.noarch
Feb  7 11:29:27 dev-mk dbus: avc:  received policyload notice (seqno=3)
Feb  7 11:29:27 dev-mk dbus: avc:  received policyload notice (seqno=3)
Feb  7 11:29:27 dev-mk dbus: avc:  received policyload notice (seqno=3)
Feb  7 11:29:27 dev-mk dbus: avc:  received policyload notice (seqno=3)
Feb  7 11:29:28 dev-mk dbus: [system] Reloaded configuration
Feb  7 11:32:49 dev-mk yum[19514]: Updated: selinux-policy-targeted-3.9.7-29.fc14.noarch

Comment 4 Daniel Walsh 2011-02-17 14:56:25 UTC
I don't think so.  I just checked on my Update f14 box and it looks fine.


Miroslav can  you check some machines there?

Comment 5 Daniel Walsh 2011-02-17 14:56:57 UTC
sandbox should really check this and inform the user that it will not work.

Comment 6 Daniel Walsh 2012-12-06 19:54:56 UTC
Current sandbox checks this.


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