12:23 p.m.
On Thu, 2007-10-18 at 08:19 -0400, Gene Heskett wrote:
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@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@coyote audit]# vim audit.rules
[root@coyote audit]# service auditd restart
Stopping auditd: [ OK ]
Starting auditd: [ OK ]
----------
isn't the real problem, so what do the experts here think?
I don't know the rule syntax, but just looking at the source, it appears
to me that the rule on line 15 is malformed (at least compared to the
others). If that rule is not complete in itself, the error would appear
when it tries to use the following line to complete it.
What happens if you comment line 15?
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?
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs