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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.