Bug 1128838

Summary: auditctl can not write to files
Product: Red Hat Enterprise Linux 6 Reporter: Patrik Kis <pkis>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Patrik Kis <pkis>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.7CC: dwalsh, mmalik, sgrubb
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.7.19-261.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-22 07:08:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Patrik Kis 2014-08-11 15:37:32 UTC
Description of problem:
auditctl is running with auditctl_t context and therefore its output can't be redirected to a file. The latest audit package introduced a feature that auditctl -l list the rules in form that can be loaded again, but this would be interesting if the output could be at sent to a file.

Version-Release number of selected component (if applicable):
audit-2.3.7-5.el6
selinux-policy-3.7.19-231.el6

How reproducible:
always

Steps to Reproduce:
# auditctl -w /bin/date -p x -k watch-date
# auditctl -l
-w /bin/date -p x -k watch-date
# cat /root/a
# cat /tmp/a
# ausearch -m avc -ts recent
----
time->Mon Aug 11 17:28:47 2014
type=PATH msg=audit(1407770927.466:337): item=1 name=(null) inode=3393 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL
type=PATH msg=audit(1407770927.466:337): item=0 name="/sbin/auditctl" inode=74764 dev=fd:00 mode=0100750 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:auditctl_exec_t:s0 nametype=NORMAL
type=CWD msg=audit(1407770927.466:337):  cwd="/root"
type=EXECVE msg=audit(1407770927.466:337): argc=2 a0="auditctl" a1="-l"
type=SYSCALL msg=audit(1407770927.466:337): arch=c000003e syscall=59 success=yes exit=0 a0=2022350 a1=2023de0 a2=1fd7c00 a3=7fffbda49e30 items=2 ppid=6794 pid=18424 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="auditctl" exe="/sbin/auditctl" subj=unconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1407770927.466:337): avc:  denied  { write } for  pid=18424 comm="auditctl" path="/root/a" dev=dm-0 ino=74624 scontext=unconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
#
#
# setenforce 0
# auditctl -l >/tmp/a
# cat /tmp/a
-w /bin/date -p x -k watch-date
#

Actual results:
auditctl -l can not be redirected to a file

Expected results:
At least writing to /tmp dir would be desirable.

Comment 1 Steve Grubb 2014-08-11 15:55:11 UTC
I'm not sure /tmp would be a good place because audit rules are "secret". You'd have to worry a normal user might see them. I'd think that /root would be a typical place, though, since root users will be able to run auditctl. Another safe place might be /etc/audit/.

Comment 2 Daniel Walsh 2014-08-12 12:16:58 UTC
Not sure why we are transitioning from unconfined_t to auditctl_t?  Most likely this transition should be removed.

Comment 3 Steve Grubb 2014-08-12 12:22:30 UTC
It might be to protect the audit rules in the kernel from unauthorized modification. I presume the rules in /etc/audit/audit.rules can only be read by auditctl_t and then the kernel can only be written to from that same domain. Its just a guess.

Comment 4 Daniel Walsh 2014-08-12 13:42:13 UTC
Well unconfined_t can read/write anything.  Having confinement for sysadm_t would be fine, although, I would argue somewhat useless also.  sysadm_t can setenforce 0

Comment 5 Miroslav Grepl 2014-09-03 14:32:07 UTC
I would remove the transition from unconfined_t.

Comment 6 Miroslav Grepl 2015-03-02 15:12:48 UTC
commit 5b856315b185aba62390896127c7317ba6003413
Author: Miroslav Grepl <mgrepl>
Date:   Mon Mar 2 16:11:23 2015 +0100

    remove transition from unconfined user to auditctl.

Comment 9 errata-xmlrpc 2015-07-22 07:08:16 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1375.html