Re: Secure Linux From Scratch

> I suggest the SLFS book be the same as the LFS book, and SBLFS be like
> BLFS, as far as layout. With things like, Pax, et_dyn, propolice, libsafe,
> or audited packages, it doesn't make any sence to use one but not the
> other.

I agree with layout, since it is very practical, although some objections to 
this recently came to light at lfs-dev. Building the base system ((S)LFS) 
with security in mind deserves a book on its own, since many packages must be 
changed and to explain a LOT of things from a security prespective. But my 
"problem" lies within the fact that a secure system must be build as one, not 
as an LFS with "security changes" i.e. to simply choose what to secure. Say 
someone installs libsafe only (since it is easy and doable at any time) and 
skips the propolice patches as a hassle. BINGO, this user has a false sence 
of safety, thinking that he protected his/her system. Not very educational, 
don't you think? The build procedure must follow strictly a security policy 
that we must design. A disclaimer of some sort should be used to explain that 
patching selected pieces leaves the system in danger.

> Everyone has the option to only follow parts of the book they want
> to anyway. (S)BLFS are components that not everyone will use, like
> networking. I also think its a good idea to keep networking out of SLFS
> since its a massive subject and should be seperated for better detail.

Out of SLFS I agree (although a computer not connected to some sort of network 
anywhere in the world is probably a turned off one), but definetely not 
skipped. Beyond buffer overflows and password cracking (both primarily local) 
exploiting network facilities of the system makes the third prime target of 
"evil men" and certainly gives anyone motive to take care of everything else 
(honestly, does anyone believe that a secure system has to do with protecting 
buffer overflows from local users? A local user just resets and boots from a 
floppy....no matter how good a propolice patch is)

> 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.

No comment, have to read on these first...sorry 

> I need to update the propolice hint and I'll start auditing coreutils, and
> try to come up with a security/auditing policy draft. This presents another
> problem. The coreutils team doesn't want to hear about bugs in v5.0, they
> expect me to use their cvs version, so if fixes are found/made, we will
> either have to use more patches, or the cvs version, at least untill a
> stable slfs book version is made.

I think we should begin at least a draft. Will start working on one really 
soon...maybe tomorrow. Let's start pouring ideas in.

> I'm not on the lfs-dev list, is this discussion going to move there?

Could be mentioned, but this subject I think holds the right to a separate 
list (hopefully, people will join in). HOwever, coordination with the 
developing brains is in order. We shall see how this turns out.

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