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). > session include system-auth > > > >> I'm a bit less concerned with it now after all this discussion, but I > >> doubt if I'll bring it back in. Why? Well, so far, the instructions > >> as to how to recover the system once its been disabled have not been > >> good enough to re-enable everything, so even if its set permissive, my > >> logs will have many kilobytes a day saying that this or that was > >> blocked. My nightly amanda run probably makes 50k of entries all by > >> itself. > >> > >> Those recovery instructions should be in a 'man selinux' but I don't > >> recall seeing them in there when I did look 2 weeks ago. Were they, > >> and I can't read? > > > >Do you mean how to relabel your filesystems? > > Yes. There was something about touching a file on /, which I tried > several times, but I had to set it permissive before amanda could run. > amanda is locally built from the most recent snapshots, sometimes 3-4 > times a week. That tarball install is not open for discussion, I do the > canary work for amanda. > > >That is mentioned there as > >well as in the Fedora SELinux FAQ, and rc.sysinit should do it > >automatically upon booting a selinux-enabled kernel after previously > >running disabled. Possibly it needs to run fixfiles with the -F flag to > >force relabeling of even customizable contexts. File bugs on the > >appropriate packages (initscripts if it isn't working correctly, > >libselinux for the man page). > > 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. -- Stephen Smalley National Security Agency
