Re: Secure Linux From Scratch

On Friday 19 December 2003 02:04 pm, Robert Day wrote:
> 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)

If someone can assist me I have one or two computers that could be set up as a 
webserver, I am not sure of the upload speed of my cable modem, I have gotten 
download rates of 368KBs off of a few close mirrors, most mirrors in North 
America it gets 128+KBs download.

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