Bug 671002 - SELinux is preventing /usr/sbin/sendmail.sendmail from using the 'execstack' accesses on a process.
Summary: SELinux is preventing /usr/sbin/sendmail.sendmail from using the 'execstack' ...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 14
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:c19e187c596...
: 671001 671011 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-19 21:28 UTC by Nikita Bige
Modified: 2011-01-24 06:56 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-24 06:56:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nikita Bige 2011-01-19 21:28:41 UTC
SELinux is preventing /usr/sbin/sendmail.sendmail from using the 'execstack' accesses on a process.

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

If you believe that sendmail.sendmail should be allowed execstack access on processes labeled system_mail_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 sendmail /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:system_mail_t:s0-s0:c0.c1023
Target Context                system_u:system_r:system_mail_t:s0-s0:c0.c1023
Target Objects                Unknown [ process ]
Source                        sendmail
Source Path                   /usr/sbin/sendmail.sendmail
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           sendmail-8.14.4-10.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-20.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 2.6.35.10-74.fc14.x86_64 #1
                              SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64
Alert Count                   4
First Seen                    Mon 17 Jan 2011 06:01:02 PM MSK
Last Seen                     Wed 19 Jan 2011 08:44:50 PM MSK
Local ID                      9b2d905d-2cba-4d95-9341-e70723b3b93a

Raw Audit Messages
type=AVC msg=audit(1295459090.453:76): avc:  denied  { execstack } for  pid=29231 comm="sendmail" scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tclass=process

sendmail,system_mail_t,system_mail_t,process,execstack
type=AVC msg=audit(1295459090.453:76): avc:  denied  { execmem } for  pid=29231 comm="sendmail" scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tclass=process

sendmail,system_mail_t,system_mail_t,process,execstack
type=SYSCALL msg=audit(1295459090.453:76): arch=x86_64 syscall=mprotect success=yes exit=0 a0=7fff3497e000 a1=1000 a2=1000007 a3=7fd2d6864000 items=0 ppid=5840 pid=29231 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=2 comm=sendmail exe=/usr/sbin/sendmail.sendmail subj=system_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null)
sendmail,system_mail_t,system_mail_t,process,execstack

#============= system_mail_t ==============
allow system_mail_t self:process { execstack execmem };

Comment 1 Daniel Walsh 2011-01-19 21:34:42 UTC
This does not make much sense unless you have some strange libraries installed.

Are you using standard sendmail?

Comment 2 Nikita Bige 2011-01-20 08:14:58 UTC
Yes, sendmail is standart from fedora repo. I didn't change it

Comment 3 Miroslav Grepl 2011-01-20 09:08:17 UTC
*** Bug 671001 has been marked as a duplicate of this bug. ***

Comment 4 Miroslav Grepl 2011-01-20 09:08:41 UTC
*** Bug 671011 has been marked as a duplicate of this bug. ***

Comment 5 Miroslav Grepl 2011-01-20 09:15:18 UTC
Could you try to look for libraries that are marked as requiring execstack


# find /lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X 
# find /usr/lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X 

or

# find /lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X 
# find /usr/lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X

Comment 6 Nikita Bige 2011-01-20 15:46:46 UTC
# find /lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X 
# find /usr/lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X
X /usr/lib64/nvidia/libcuda.so
X /usr/lib64/nvidia/libnvidia-compiler.so.1
X /usr/lib64/nvidia/libcuda.so.260.19.29
X /usr/lib64/nvidia/libOpenCL.so.1.0.0
X /usr/lib64/nvidia/libnvidia-compiler.so.260.19.29
X /usr/lib64/nvidia/libOpenCL.so.1
X /usr/lib64/nvidia/libcuda.so.1
X /usr/lib64/libnnz11.so
# find /usr/lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X                                               
X /usr/lib/nvidia/libcuda.so
X /usr/lib/nvidia/libnvidia-compiler.so.1
X /usr/lib/nvidia/libcuda.so.260.19.29
X /usr/lib/nvidia/libOpenCL.so.1.0.0
X /usr/lib/nvidia/libnvidia-compiler.so.260.19.29
X /usr/lib/nvidia/libOpenCL.so.1
X /usr/lib/nvidia/libcuda.so.1
X /usr/lib/vmware/bin/vmware-vmx-stats
X /usr/lib/vmware/bin/vmware-vmx-debug
X /usr/lib/vmware/bin/vmware-vmx

Comment 7 Nikita Bige 2011-01-20 16:04:55 UTC
# ldconfig -p | awk '{print $4}' |  xargs execstack -q 2> /dev/null | grep ^X
X /usr/lib64/nvidia/libnvidia-compiler.so.260.19.29
X /usr/lib/nvidia/libnvidia-compiler.so.260.19.29
X /usr/lib64/libnnz11.so
X /usr/lib64/nvidia/libcuda.so.1
X /usr/lib/nvidia/libcuda.so.1
X /usr/lib64/nvidia/libcuda.so
X /usr/lib/nvidia/libcuda.so
X /usr/local/zend/lib/libcrypto.so.0.9.8  <--- I think that that the culprit has been this library

X /usr/lib64/nvidia/libOpenCL.so.1
X /usr/lib/nvidia/libOpenCL.so.1

Comment 8 Daniel Walsh 2011-01-20 20:43:34 UTC
If you execute 

execstack -c  /usr/local/zend/lib/libcrypto.so.0.9.8 

And everything works correctly you  might have solved the problem.

You might want to try clearing the flag on all the libraries since they probably do not need them.

Comment 9 Nikita Bige 2011-01-24 06:56:31 UTC
execstack -c  /usr/local/zend/lib/libcrypto.so.0.9.8 

solved the problem


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