Re: How NSA access was built into Windows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux