Re: Secure Linux From Scratch

On Fri, 2003-12-19 at 07:53, Ken Moffat wrote:
> On Thu, 18 Dec 2003, ashes wrote:
> 
> >
> > >From what I understand et_dyn is broken in gcc-3.3. So without adding more
> > patches, we could downgrade to gcc-3.2, or upgrade to gcc-3.4 with a
> > backport/patch.. and that needs glibc-2.3.3. Just something to consider, but
> > we'll need to do one of these to take advantage of Pax.
> >
> 
>  I think that using a different version of gcc, let alone a different
> version of glibc, should be a non-starter for an LFS project.  I can
> cope with patching the version which is in LFS, obviously, but if SLFS
> becomes too far removed from the things in LFS then the amount of
> testing required will increase exponentially (and I don't mean the
> security testing people here are focussed on, I mean the "can it build
> everything correctly" testing).

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?
"A bug has been found in SLFS 5.1 (aka Valentine) released Feb 14, 2004.
This bug allows a remote attacker to overflow the stack of any program
compiled with gcc 3.4 that uses XXXX function call, and execute
arbitrary code, leading to a possible root comprimise. The fix for this
bug is a complete rebuild of your SLFS system from the ground up. Please
refer to SLFS 5.1.1 (aka Lion) release March 1, 2004."   Not such a good
idea ;)

Now whether or not such a thing could happen, I dunno - and frankly it
is a moot point..  the essence of my argument still stands. No
application and no Os can be secure, if the underlying technology is
insecure. (ie. your box is only as secure as the local users allow. Any
local user can reboot the box, clear the CMOS if it is passworded, boot
floppy or CD, and comprimise root on the box. Unless the box is in a
safe, with alarms around it, in a building with armed guards, and a
direct link to the police should anyone enter the building, the system
can be comprimised.)

My suggestion is only use released packages, that have been tested, and
secured.

   Rob Day (BOFH)

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