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. -- Stephen Smalley National Security Agency -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
