Re: Secure Linux From Scratch
Robert Day <[email protected]>
| Newsgroups | gmane.linux.lfs.security |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 2003-12-19 at 14:54, ashes wrote: > On December 19, 2003 08:17 am, Robert Day wrote: > ... > > Simple answer, if Pax requires that much, then we don;t use it. Not till > > the required subsystems are available as part of LFS. We're not > > replacing LFS here with a cutting edge system. One of the key points in > > security is using tested, stable packages. You can't build a secure box > > using insecure packages as a foundation. If the gcc 3.4, being so new, > > has a flaw, that flaw propagates to every package in the system. Imagine > > the errata we'd have to release if a bug was found in gcc that allowed a > > buffer overflow to occur in any package compiled with that compiler that > > used XXXX system call? > > Not all of gcc-3.4 needs to be imported, just the -pie patch. By the time the > book is stable, it may not be so cutting edge. We still do not have SLFS > project goals defined, but certainly they would all have to be met before the > release, and tested to the best of our ability. Gcc-3.3 is still an option, > its just not as powerfull as gcc-3.4's. Personaly I have no interest in > testing the gcc-3.3 method because I know it will become obsolete in the not > to distant future. If anyone else wants to get gcc-3.3's et_dyn working feel > free. There's no reason to jump the gun on this and pop out a release asap. > If we do, it would make the project less creditable, and secure. It should be > unique. I feel it should be something like a good crash course in hacking, > and of course how to prevent it on you. Instead of just saying its secure, > show real life examples why. I think that implies we have to try to break > every aspect of the system, and don't issue a release untill is passes any > torture we can cook up. > Agreed... the system build as a byproduct of SLFS must be as secure as we can make it... And thus, releases cannot be pushed out the door... But, the SLFS "Work in Progress" can be... The related documentation surrounding the packages... This can be put online somewhere as just what is says - a work in progress... would be a good way to get users to see and read the book as we get it developed, and get some feedback outside our small development community. But, we are jumping the gun on what packages to use.. Remember, we DO need a roadmap, project "statement", and "member developers" list before we can proceed far... the statement I think should come first... What exactly do we want this book to be? Then a "Goals" statement... what do we want the end result of following the book? Do we want a Secure'd LFS, a freshly built from the ground up LFS? A Hybrid of both? (cause let's face it, not all of us have a machine dedicated to iron-clad security.. some of us want a useable system with GUI and games and other niceties, but are online, and want some sort of security running around the box there somehow....) So, let's chill the package arguments for a day or two and get a foundation to build on... you can;t build the house then dig the basement under it (well, you can but it's folly to do so).. you want the foundation there first.. Rob Day (BOFH) -- http://linuxfromscratch.org/mailman/listinfo/lfs-security FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page