Secure Linux From Scratch

[ashes]

On December 1, 2003 11:40 am, Andrew Calkin wrote:
> On Mon, Dec 01, 2003 at 11:29:49AM -0500, ashes wrote:
> > With LFS basicly all patches are manditory, with exception of the
> > coreutils patches. In SLFS all patches would be optional. But I guess
> > this would have to depend on the security policy. Can a web server, a
> > desktop, and a bank machine have the same generic policy, and base
> > system?
>
> So you are proposing something more like a BLFS approach? Where packages
> or steps are installed as per users personal tastes? That is what I was
> thinking of too, pretty much. Also, how do the differnent procedures work
> together, and have you noticed much/any incompatibility with other
> programs no longer compiling? I must admit I am new to this, so feel
> free to throw me some links and/or just RTFM's and I'll try to get up
> to speed.
>
> //Andrew

This will build everything I use except grub, kernel, and X needs a patch.
http://www.linuxfromscratch.org/hints/downloads/files/propolice.txt
http://www.research.ibm.com/trl/projects/security/ssp/

This is Pax random address space. Im not fully clear on exactly what this is, 
or does. I have more to read about it. It works on my system. The entire LFS 
base system can be built with this, except grub, and the kernel. I have built 
XFree86 with it without problems. KDE wouldn't though (needs patches). Might 
have problems with other BLFS software... With the gcc-3.4 -pie" backport, 
and binutils-2.14.90.0.5+ -pie support, binaries and libraries are now 
'dynamic objects' instead of dynamic exec, or lib. (They seem to be built 
partialy stripped with `gcc -g`, need to read more about this) This, and 
propolice work together, and work with nptl/2.6.
http://pageexec.virtualave.net/
You can search google for other copies of this patch.
http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/gcc/gcc33-pie.patch
I think this is part of the reason Pax isn't in the vanila kernel.
http://old.lwn.net/1998/0806/a/linus-noexec.html

This is also the dude who makes nALFS as far as I can tell. Nice howto.
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/

This is a proactive auditing tool. (Uses a lot of CPU, be carefull)
http://bfbtester.sourceforge.net/

This is full bounds checking GCC patch. Its great for auditing.
http://web.inter.nl.net/hcc/Haj.Ten.Brugge/

I want to check this out soon.
http://www.gnu.org/directory/security/net/libsafe.html

The -fstack-protector and -pie CFLAGS/CXXFLAGS, in my opinion, should be used 
on the whole system where posible, on all systems. They consume very little 
resources on my desktop, I dont know about benchmarks. They should also be 
used together with intrudion detection (log sniffers).
Bfbtester and -fbounds-checking should be used (not nessesarily installed) on 
the build system. A binary built with -fbounds-checking is around ten times 
bigger and slower then normal, but gives very good debugging info, and will 
kill/crash on any stack or heap overflow.

As you can see, so far I am concentrating on gcc, libc, and binutils. I 
haven't considered an auditing policy, and I dont know when enough is enough. 
There is much more out there then gcc patches that needs to be checked out, 
but so far this stuff is transparent to the end user. Theres no way this can 
all fit in a hint, it has to be a book.

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