Re: Secure Linux From Scratch

On December 2, 2003 01:00 pm, Frank R. Wesselmann wrote:
> <lurker emerging from the shadows>
>
> Hi y'all, thought I'd add a "consumer voice" to this discussion:
>
> A guided approach to hardening an LFS system would certainly be much
> appreciated, so SLFS would be a great book to have.  But for it to be a
> realistic project, I think a limited scope must be defined.  There is just
> no way a project like this can feasibly dig up vulnerabilities in the
> various packages.  That's the job of the package maintainers and the user
> base at large.
>
> Our community could, however, make an organized effort to keep abreast of
> discoveries and fixes (this list seems to do at least some of that).
> Customizations, such as those already mentioned in this thread for gcc,
> also would seem appropriate and most likely candidates for reference in the
> LFS book, though they would need to be thoroughly discussed.  But I have
> yet to see anyone make any mention of the most basic and obvious issue:
> configuration.
>
> The LFS book (and BLFS) certainly seem to make a serious effort to avoid
> SUID vulnerabilities and to provide a reasonably safe but useful base
> configuration.  What is sorely lacking, however, is a more fundamental
> description of the need (or lack thereof) for SUID executables and what the
> consequences of flipping this bit really are, strategies for individual
> packages, and other issues along these lines.  Yes, all this is available
> in the packages' documentation -- mostly and to varying degrees of
> completeness and comprehensibility.  But that's an awful lot of work for
> the LFS user, just for the base LFS system which is almost useless by
> itself.
>
> A book that can help us configure a limited but useful system (i.e. a
> controlled environment) to maximize security would seem to be supremely
> useful.  So it would have to be SLFS and SBLFS in one, otherwise I think it
> should just be an appendix in LFS.  IMHO, that is.
>
> frw
> <fading back into the darkness>

Selinux has ways of eliminating suid. I personaly am not impressed with 
Selinux, and I'm looking for another way around suid. There are 
vulnerabilities in stable code we use in LFS, patch-2.5.4, and coreutils-5.0 
have yet-to-be-exploited vulnerabilities which are fixed in newer version. I 
discovered the vulnerability with bfbtester before learning redhat and others 
had patched their versions. Take a look at the recent kernel-2.4.23 post, a 
known vulnerability in the stable release was almost ignored, untill someone 
exploited it. Basic security configuration is trivial, its already very well 
doccumented. The base issue with all vulnerabilities is the code itself, a 
hardened toolchain can help reduce the effects of unknown vulnerabilities. I 
feel we, and others, should proactively attack our own software the same way 
a hacker would to find these yet-to-be-exploited bugs. How else can we trust 
our software? At this point I am only interested in the LFS base system, 
SBLFS is over my head right now. I also want to be very carefull not to make 
the system unuseable on first boot, which is something that selinux will do. 
Security which inhibits X etc, should be optional, or no one will use it.

-- 
cendres at videotron dot ca
gpg --keyserver wwwkeys.pgp.net --recv-keys 0xD4E26E10

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page