SELinux revisited

[Gene Heskett]

On Thursday 18 October 2007, Gene Heskett wrote:
>On Thursday 18 October 2007, Andy Green wrote:
>>Somebody in the thread at some point said:
>>> Greetings;
>>>
>>> Running 2.6.23 here, on a AMD XP-2800, gig of ram, lots of drive.
>>>
>>> I thought maybe I should give selinux another chance here.  So I removed
>>> the selinux=0 in my grub.conf, and edited its .conf file in
>>> /etc/sysconfig to set it for permissive.
>>>
>>> On the reboot, the relabel wasn't done, so I looked around and reset a
>>> fresh /.autorelabel file and rebooted again.  It was already present
>>> however.
>>>
>>> This time it did a very short autorelabel, maybe 2 screens full and was
>>> done in just a couple of seconds, at which point it went into yet another
>>> reboot cycle making me think it was stuck in a loop or something.
>>
>>Sounds like you are going about it in a good way FWIW.
>>
>>> But the next reboot then had auditd advise me there was an error in line
>>> 16 of /etc/audit/auditd.rules.
>>
>>That file looks like this here, in full:
>>
>># This file contains the auditctl rules that are loaded
>># whenever the audit daemon is started via the initscripts.
>># The rules are simply the parameters that would be passed
>># to auditctl.
>>
>># First rule - delete all
>>-D
>>
>># Increase the buffers to survive stress events.
>># Make this bigger for busy systems
>>-b 320
>>
>># Feel free to add below this line. See auditctl man page
>>
>>
>>Here's the state of the selinux packages here for reference
>>
>># rpm -qa | grep selinux
>>libselinux-2.0.14-9.fc7
>>libselinux-python-2.0.14-9.fc7
>>selinux-policy-targeted-2.6.4-48.fc7
>>selinux-policy-2.6.4-48.fc7
>># rpm -qa | grep audit
>>audit-libs-python-1.5.6-2.fc7
>>audit-libs-1.5.6-2.fc7
>>audit-1.5.6-2.fc7
>
>All fc6 here, but uptodate.
>
>># chkconfig --list | grep audit
>>auditd          0:off   1:off   2:on    3:on    4:on    5:on    6:off
>>
>>I would nuke the entries at the end of your /etc/audit/auditd.rules and
>>retry.
>
>I'll give that a shot tomorrow, its getting sleepy out around here, 4am &
> I've already lost any chance at beauty sleep, which wouldn't help at my age
> anyway. :)
>
>>-Andy
>
>Thanks Andy.
>
Ok, up again, nuked a pint of coffee but its too hot yet.

I commented that line 16 in audit.rules, and it moved the error to line 17, so 
I commented that one too.

Step & repeat until there is only one active line in the file, line 15.
--------------
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page

-a exit,always -S chroot
#-a exit,always -S chdir -F obj_type=dhclient_t
#-a exit,always -S chdir -F obj_type=sendmail_t
#-a exit,always -S chdir -F obj_type=mcstransd_t
#-a exit,always -S chdir -F obj_type=sshd_t
#-a exit,always -S chdir -F obj_type=ntpd_t
#-a exit,always -S chdir -F obj_type=samba_t
#-a exit,always -S chdir -F obj_type=named_t
#-a exit,always -S chdir -F obj_type=klogd_t
#-a exit,always -S chdir -F obj_type=crond_t
#-a exit,always -S chdir -F obj_type=httpd_t
#-a exit,always -S chdir -F obj_type=auditd_t
#-a exit,always -S chdir -F obj_type=portmap_t
#-a exit,always -S chdir -F obj_type=syslogd_t
-----------
Now it seems to me that those rules were there for a reason, and to have to 
comment all but the first one out to get rid of the error:
---------
[root at coyote audit]# service auditd restart
Stopping auditd:                                           [  OK  ]
Starting auditd:                                           [  OK  ]
Error sending add rule data request (Unknown error 524)
There was an error in line 27 of /etc/audit/audit.rules
[root at coyote audit]# vim audit.rules
[root at coyote audit]# service auditd restart
Stopping auditd:                                           [  OK  ]
Starting auditd:                                           [  OK  ]
----------
isn't the real problem, so what do the experts here think?

SELinux is running in permissive mode, and seems to be logging res=success for 
everything so far, so it may be possible to set it to targeted.  I figured if 
I tried it on a known, fully working system, that would be a hell of a lot 
more accurate test than trying to make it work on a fresh install, which 
forced me to disable it months ago.

Would it have logged res=denied for anything if set to permissive?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
A Vulcan can no sooner be disloyal than he can exist without breathing.
		-- Kirk, "The Menagerie", stardate 3012.4