Bug 464079

Summary: avc: denied { search / unlink } for comm="audispd"
Product: Red Hat Enterprise Linux 5 Reporter: Alexander Todorov <atodorov>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED ERRATA QA Contact: Alexander Todorov <atodorov>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: dwalsh, mmalik, syeghiay
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-20 21:30:58 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:

Description Alexander Todorov 2008-09-26 08:01:32 UTC
Description of problem:
During upgrade with yum from RHEL5.2-Server to RHEL5.3-Server-20080922.0 there's a SELinux denial.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-2.4.6-158.el5

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL5.2-Server, @everything
2. configure yum repos for latest release
3. do yum update
  
Actual results:
SELinux denial

Expected results:
No SElinux denial

Additional info:
audit(1222363412.600:80): audit_pid=0 old=6466 by auid=4294967295 subj=system_u:system_r:auditd_t:s0
audit(1222363412.718:81): avc:  denied  { search } for  pid=6408 comm="audispd" name="sbin" dev=dm-0 ino=7929857 scontext=system_u:system_r:audisp_t:s0 tcontext=system_u:object_r:sbin_t:s0 tclass=dir
audit(1222363412.718:81): arch=c0000032 syscall=1210 success=no exit=-13 a0=60000fffff8927cf a1=60000fffff892690 a2=200000080036c6b8 a3=2000000800382580 items=0 ppid=6406 pid=6408 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="audispd" exe="/sbin/audispd" subj=system_u:system_r:audisp_t:s0 key=(null)
audit(1222363412.720:82): audit_pid=6406 old=0 by auid=4294967295 subj=system_u:system_r:auditd_t:s0


Also seeing to the above on i386:
audit(1222364140.365:122): avc:  denied  { unlink } for  pid=9002 comm="audispd" name="audispd_events" dev=dm-0 ino=54526127 scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:audisp_var_run_t:s0 tclass=sock_file
audit(1222364140.365:123): audit_pid=0 old=9000 by auid=4294967295 subj=system_u:system_r:auditd_t:s0
audit(1222364140.601:124): audit_pid=25445 old=0 by auid=4294967295 subj=system_u:system_r:auditd_t:s0

Comment 2 Daniel Walsh 2008-09-29 18:45:09 UTC
what is audispd labeled?

ls -lZ /sbin/audispd?

Comment 3 Alexander Todorov 2008-09-30 10:37:17 UTC
After install & before upgrade:
-rwxr-x---  root root system_u:object_r:sbin_t         /sbin/audispd

After upgrade:
-rwxr-x---  root root system_u:object_r:audisp_exec_t  /sbin/audispd

Comment 4 Daniel Walsh 2008-09-30 15:15:07 UTC
Ok well the second avc should disappear after upgrade also since audispd will run in a different domain then auditd_t which is allowed to unlink the sock_file.

Fixed in selinux-policy-2.4.6-161.el5

Comment 10 Daniel Walsh 2008-10-22 15:50:46 UTC
So why is audispd running as auditd_t and not as audisp_t.

The following two roles should have caused auditd_t to transition to audisp_t when it execs the app.

#sesearch --allow -s auditd_t -t audisp_t
Found 1 av rules:
   allow auditd_t audisp_t : process { transition signal }; 

# sesearch --allow -s auditd_t -t audisp_exec_t
Found 1 av rules:
   allow auditd_t audisp_exec_t : file { read getattr execute }; 

What is the label on audispd?

# ls -lZ /sbin/audispd
-rwxr-x---  root root system_u:object_r:audisp_exec_t:s0 /sbin/audispd

Comment 11 Alexander Todorov 2008-10-23 06:57:11 UTC
Context after install:
-rwxr-x---  root root system_u:object_r:sbin_t         /sbin/audispd

Context after the upgrade:
-rwxr-x---  root root system_u:object_r:audisp_exec_t  /sbin/audispd

Comment 12 Daniel Walsh 2008-10-23 14:50:01 UTC
If you do a 

# service auditd restart

what does

# ps -eZ | grep audisp

Show?

If this is running as audisp_t, then you should not see this problem any more.

Comment 13 Alexander Todorov 2008-10-24 11:10:08 UTC
OK, it's running as audisp_t and indeed I didn't see the problem. I was doing manual test but for some reason the automated one failed. 

Moving back to VERIFIED and will try to find out if this can reproduce more consistently with our automated test case.

Comment 15 errata-xmlrpc 2009-01-20 21:30:58 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0163.html