Bug 503756

Summary: Denials of setenforce are not being reported in the audit.log
Product: [Fedora] Fedora Reporter: Daniel Walsh <dwalsh>
Component: kernelAssignee: Eric Paris <eparis>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: itamar, kernel-maint, quintela, sdsmall
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-02 15:54:51 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 Daniel Walsh 2009-06-02 14:51:05 UTC 
Description of problem:

If I execute 

sandbox setenforce 0

I would expect a big denial in the audit.log

# sandbox setenforce 0
/usr/sbin/setenforce:  setenforce() failed
sh-4.0# ausearch -m avc -ts recent
<no matches>

Sadly no AVC is reported.

If I put the machine in permissive mode I do see the AVC.

#============= sandbox_t ==============
allow sandbox_t security_t:file write;
allow sandbox_t security_t:security setenforce;
Comment 1 Eric Paris 2009-06-02 15:02:28 UTC 
Do you have dontaudit on open of security_t:file?  I don't see the open...
Comment 2 Stephen Smalley 2009-06-02 15:09:38 UTC 
Ditto for security_t:dir search.
You aren't ever reaching the setenforce check in enforcing mode.
Comment 3 Daniel Walsh 2009-06-02 15:54:51 UTC 
I am an idiot, never mind.

I will allow domains to getattr on /selinux and search the selinux_t so that we can get them attempting to write the security_t file.
Comment 4 Daniel Walsh 2009-06-02 20:56:54 UTC 
BTW There is n o open of security_t.