Re: Secure Linux From Scratch

Greetings list,

	I have followed the ideas and suggestions going around in this thread and I 
decided to come forth with a few ideas of my own.
	I have built and used (not heavily yet) a CVS version of LFS (2003-12-13) 
with a few customizations. In particular:
	a. Added in chapter 6 a build section for Linux-PAM as per discribed in the 
BLFS book. It is done right before the Shadow package building. 
	b. The Shadow package get built with pam support from the beggining and there 
is no need to re-install it when in BLFS. The build procedure is a mix of the 
standard LFS build commands and BLFS suggestions that enable pam in the 
package.
	c. After shadow, inetutils are next with an extra argument for configure: 
--enable-pam. So, inetutils utilise the just installed PAM's. The rest build 
options stay the same.
	d. After booting, first thing done is instalation of OpenSSL. Obviously, such 
a library collection should be part of any even marginally secure system.
	e. Next comes the libsafe package, build and installed as described in the 
package's documentation. Nothing funcy, in plainly works. Also tried to build 
prelude HIDS in order to take advantage of libsafe's sensor feature to report 
exploitation attempts. Had a problem building the manager when libprelude is 
build with SSL support. I hope I will get around it soon. Also, I checked out 
libformat but did not use it, since after a (quick) look through the code I 
noticed some not very security-consious function selection, such as strcpy() 
and little error handling. Libsafe seems more sturdy and covers the same and 
more functions than libformat (IMHO more effectivelly).

	Everything is build with a gcc 3.3.2 patched against propolice, as per 
described in the relevant hint. No problem encountered so far. Also, I use 
linux-2.6.0-test11, patched with the propolice patch and build with gcc-3.3.2 
It compiles cleanly and is immune to the recent brk() vulnerability. I must 
also note that I use lilo instead of grub. There rises a problem that extra, 
unneeded software (bin86 and nasm) is installed for building just one 
package. I countered that by skipping the "make install" part for both bin86 
and nasm and modifing the Makefile for lilo to point to the build directories 
for the needed binaries. Then install lilo and erase the building 
directories. All is gone and less binaries in the system mean more security. 

( OT Suggestion: Would it be worth the efford to make a custom tarball of lilo 
that would contain nasm and bin86, which would temporarily build them in 
order to build lilo, and then erase them? I could do it if there is any 
need.)

	Well, just this, plainly as suggestions (or as questions, if you prefer, to 
the validity of these methods)

	As far as the SLFS format is concerned, I think I will follow a middle road 
approach. In the beggining, the whole project could start as a (rather 
extensive) hint that would cross-reference with the LFS book. Then, as it 
evolves and becomes more solid, with a wireframe well defined, it could be 
possible to merge it with the LFS book OR make a seperate edition, which ever 
best suits the needs at that time. I guess what I have in mind is the 
pure-LFS scheme. When it came to light it was a hint. Nothing obligatory, in 
no way a part of LFS, but a damn good thing to do. When it was mature enough, 
it merged with the main LFS. Same thing with the SLFS. A draft could be 
created to start working on it and then decide the final format, depending on 
the size and complexity of the result.
	So, the way I see it, the idea could start as a hint so as the developing 
team could work on it, having feedback etc. and also allow the adventurous to 
try it out, (in order to provide the feedback needed).
	In conclusion, If I have to side with any of the two proposals I stick with 
the second (cross-referencing the LFS book, mainly because it has the 
advantage of reproducing less information), but only for a short time. I 
think the changes will become immense and eventually require their own place.

	I would also like to add a slightly "philosophical" point. To properly secure 
a system, the user (admin, whatever) must be ultimately familiar with it. It 
is no use installing libsafe, for instance, if one does not know what format 
string vulnerabilities are or what packages are suspectible to them. So, a 
SLFS book should address these issues to, if it is to be of (serious) 
educational value. What are the suggestions (if any) on this topic? 
Mentioning simply the well known articles (Aleph's 1 "Smashng the stack for 
fun and profit" etc) will be deemed sufficient or should the reader be 
provided with first hand material? Writing such a section could be a daunting 
task, very interesting nevertheless and surely worth the efford.

	One final note: I installed libsafe following the ideas of a previous post on 
this thread. As far as I can tell it is still actively developed and is a 
very good security measure to have lying around. If it is going to be 
included in a SLFS approach, would building the SUID binaries statically have 
a meaning? From my barely existing programming skills I understand that 
building a binary statically means linking it against the standard library, 
the one that libsafe is trying to circumvert. Then, all the unsafe library 
functions would be hardwired to (the most) security critical binaries, with 
no way to countermeasure such situation. The problem would be addressed if 
they would be linked statically against the functions libsafe provides. A 
patch on this (or sugestions on how to make one) would be of great use. All 
these of cource only if my assumptions are correct :-)

	Hope was not a complete pain. Just my $(no_value_worth_mentioning).

himicos

PS. All custom comands used to buid the packages are available on request. I 
did not include them to save bandwidth :-)
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page