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?
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?
Normally the default audit.rules doesn't contain any filters. Perhaps the audit maintainer accidentally shipped an audit.rules with some test filters? Those particular filters might not work on older kernels.
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?
No, because permissive doesn't return an error from the system call. So you are still looking for avc messages, e.g. /sbin/ausearch -i -m avc, as indications that something would have been denied by SELinux. setroubleshoot should report them too if you have that installed.
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?
selinux@lists.fedoraproject.org
-
Gene Heskett -
Matthew Saltzman -
Stephen Smalley