Bug 597565 - sudo ausearch can be pointed at non auditd_log_t files
Summary: sudo ausearch can be pointed at non auditd_log_t files
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mlmmj
Version: rawhide
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Steve Grubb
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-29 15:54 UTC by LC Bruzenak
Modified: 2010-06-03 21:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-03 21:19:22 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description LC Bruzenak 2010-05-29 15:54:30 UTC
Description of problem:
Running "sudo ausearch" can give the user access to files otherwise DAC-protected.

Version-Release number of selected component (if applicable):
All.

How reproducible:
Always

Steps to Reproduce:
1.As non root user, try to "cat /etc/audit/auditd.conf" 
2.This fails. Same user granted sudo ausearch does "sudo ausearch -if /etc/audit/auditd.conf"
3.The file values are shown.
  
Actual results:
A user granted sudo ausearch can now see otherwise DAC-protected files.

Expected results:
The policy would restrict ausearch to only reading files of type auditd_log_t.

Additional info:
I think this is a policy mod which should be incorporated into the baseline policy.

Comment 1 Steve Grubb 2010-06-01 13:19:41 UTC
This would not be a audit problem. You would need to make sure that sudo's pam stack is set such that you are in a restricted role and that selinux policy forbids ausearch from opening any other files.

Comment 2 LC Bruzenak 2010-06-01 14:36:00 UTC
I agree; I don't know about the pam part but policy certainly. Would I reassign it to "policy"?

Comment 3 Daniel Walsh 2010-06-01 15:11:54 UTC
Reassiging to rawhide.  

I think you are requesting that an unconfined user setup to use sudo would suddenly transition to another role when running ausearch?

Comment 4 LC Bruzenak 2010-06-01 15:46:40 UTC
I don't know if it is really transiting to another role; maybe the role it is in is too powerful? I believe it is now allowed to cross DAC boundaries. Here is an example (jcdxdev account is only allowed to ausearch in the sudoers file):

[jcdxdev@slim ~]$ id
uid=501(jcdxdev) gid=501(jcdxdev) groups=501(jcdxdev) context=user_u:user_r:user_t:s0
[jcdxdev@slim ~]$ cat /etc/audit/auditd.conf
cat: /etc/audit/auditd.conf: Permission denied
[jcdxdev@slim ~]$ sudo !!
sudo cat /etc/audit/auditd.conf
[sudo] password for jcdxdev: 
Sorry, user jcdxdev is not allowed to execute '/bin/cat /etc/audit/auditd.conf' as root on slim.
[jcdxdev@slim ~]$ sudo ausearch -if /etc/audit/auditd.conf
[sudo] password for jcdxdev: 
----
time->Wed Nov 11 18:53:36 1970
#
----
time->Wed Nov 11 18:53:36 1970
# This file controls the configuration of the audit daemon
----
time->Wed Nov 11 18:53:36 1970
#
....


The DAC/MAC on the auditd.conf file is:
-rw-r-----  root root system_u:object_r:auditd_etc_t:s15:c0.c1023 /etc/audit/auditd.conf

whereas the audit files intended to be searched are:
-rw-------  root root system_u:object_r:auditd_log_t:s15:c0.c1023 audit.log

I would think it would be best to say that the ausearch executable should only be able to access files of the auditd_log_t type. Right?

Here is the sudoers entry (machine name "slim"):
jcdxdev slim=/sbin/ausearch

Comment 5 Steve Grubb 2010-06-01 19:26:59 UTC
sudo has a '-r' option to change roles.

Comment 6 Daniel Walsh 2010-06-02 19:10:40 UTC
You can add SELinux policy for this but you could also just create a script.  I would recommend that you install a shell that will only allow certain ausearch commands

Maybe just eliminate the -if flag.

# more /usr/bin/myausearch
#!/bin/sh
for i in $*;do 
	if [ $i == "-if" ]; then 
		echo '"-if" option is not allowed'
		exit -1;
	fi ; done
ausearch $*


Then just allow your user to execute myausearch

Comment 7 LC Bruzenak 2010-06-02 21:27:38 UTC
OK; thanks Dan. If you think it should be fixed this way then this bug can be closed as far as I'm concerned. I appreciate the info!


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