On Friday 19 January 2007 13:01, Stephen Smalley wrote: >On Fri, 2007-01-19 at 12:50 -0500, Gene Heskett wrote: >> On Friday 19 January 2007 10:42, Stephen Smalley wrote: >> >On Fri, 2007-01-19 at 10:03 -0500, Gene Heskett wrote: >> >> On Friday 19 January 2007 07:40, Stephen Smalley wrote: >> >> >Aside from rebuilding from source with selinux options disabled in >> >> > the compile-time configuration, you are correct - you cannot >> >> > remove the actual selinux bits from Fedora at runtime, although >> >> > you can disable their execution (boot with selinux=0). >> >> > Performing an audit of the code associated with disabling SELinux >> >> > at boot time isn't difficult, and doesn't require understanding >> >> > the rest of the SELinux code that is never reached in that case. >> >> >> >> I have removed it from the kernel, but those log messages I posted >> >> before are still in the logwatch report this morning. >> > >> >Do you mean the loginuid messages? That isn't selinux, as I said - >> > that is audit-related. You can remove pam_loginuid from your >> > /etc/pam.d/* configs. You could file a bug against it or audit >> > arguing that they should check whether audit is enabled in the >> > kernel and silently exit in that case. >> >> There are 95 files in /etc/pam.d, but pam_loginuid isn't one of them. >> Ahh, found it, good old locate to the rescue again. >> [root@coyote pam.d]# locate pam_loginuid >> /lib/security/pam_loginuid.so >> >> But I see that's the library. So whats calling it? Something in >> the /etc/pam.d/cron file since the messages all carry a crond label: >> >> # The PAM configuration file for the cron daemon >> # >> # >> auth sufficient pam_rootok.so >> auth required pam_env.so >> auth include system-auth >> account required pam_access.so >> account include system-auth >> session required pam_loginuid.so <-aha! can I nuke this line? > >Yes. That is what I said - remove pam_loginuid from all of >your /etc/pam.d/* configs. Or if there is no other session module >listed, you can always replace "pam_loginuid.so" with "pam_permit.so" to >keep things happy (i.e. stub pam module that always says yes). Ok, did that to the crond file, it was the only one squawking. [...] >> Can I run this fixfiles standalone? Looks like I can, so its working. >> Results if any later. > >Yes, fixfiles -F relabel. >That will forcibly relabel everything. Whether or not it solves your >amanda issues, I don't know - you might need to create a local policy >module to allow it to work. See audit2allow and the Fedora SELinux FAQ. Results are that it did not stay on the filesystem, but actually reached out in the /mnt/disk2 tree, which was my old FC2 drive. It also relabeled everything in /amandatapes, which is a 200GB (/dev/hdd) drive amanda treats 180GB of like a tape changer with a very quick changer mechanism using the FILE: type tape descriptor. But a quick run of amcheck as the user amanda didn't indicate any problems. /var (& one swap partition) is also on that drive, a lesson I learned about having records of a screwup if the main drive goes read-only. And I see it logged all actions to syslog, so messages is many megabytes now. I'll see how amanda runs tonight, and what sort of things are in the logwatch tommorrow. Thanks Stephen. -- 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) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
