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?
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?