Re: SLFS book chapter proposals

On Sat, Dec 20, 2003 at 09:32:32AM -0500, Robert Day wrote:
> 
> It is, IMHO, a minor detail to show examples. We're not talking about
> showing exploits to apache here, just the common buffer overflow
> methods, and other such normal backdoors that hackers would use. Nothing
> really application specific here, more like conceptual stuff.

Which can be done with a link or two with less duplication, and gives
examples of security-related websites that may be unknown to the reader.

> I see nothing wrong with distributing what has been dubbed a "Hackers'
> Howto" - After all, knowlege is power.

The info is already out there. Links should be sufficient in most cases.

> If it is decided that we should include the common exploits in our
> book, then IMHO they should be in an appendix, with links in the book
> to each appendix entry.

Hmmm, something came to mind. I do think it would be worthwhile to have
a repository of exploits or links to exploits for testing and errata
purposes. I don't believe it should be in the book, though.

> One good example is the ptrace vulnerability. Local exploit. I am sure
> y'all know about it.  (for those who don't it basically exploits a
> kernel condition, and drops you to a root shell. Very nasty, and very
> easy. as soon as any user gets local access, they are root.)  This
> exploit could be put in the general concepts..  "Compile this little
> program as user, and run it. Notice you are now in a root shell - This
> is what happens to get here, and why. Now, patch this, rebuild this, and
> try to run the exploit code again - notice the error, your system has
> just be secured agains't this common exploit". The user has learned
> something about low level security methods....  How deep the security
> theory must run to build a secure box.

That's teaching coding. But, if that exploit affected a version of the
book, it should be listed in an errata page. However, one must keep in
mind that we do not have the staff to *officially* maintain old
releases forever. That is not to say that help on the lists won't be
available.

> Chapter 1 - Security? 
>  What it is, what it is not, comitments on the part of the user.

Good choice of words. The reader must be made aware that he must be
proactive.

> Chapter 2 - But I don't need it!
>  Who needs security, who can ignore the book. Why you DO need this book.

Paranoia, anyone? I say scare the hell outta them! :)

> Chapter 3 - About the Book
>  What the reader will accomplish by reading the book, the SLFS system 
>  that he or she will have built, and what will remain for the user after
>  the book.

With emphasis on that last part.

<..>

> Part II - General Concepts
> 
> Chapter 1 - What exactly is a Secure Linux box?
>  Detailed description of a secure system and the different levels of
>  security implimented in SLFS.

IMO, there is no detailed description. It's all talking about general
concepts.

> Chapter 2 - Proof
>  Proof that security is a concern. This chapter can include the ptrace 
>  exploit, a sample code block that is exploitable, and the patched
>  version of that code that is not exploitable, and links to a few of the
>  nastier exploits released in the past year or two. ie. sshd's     
>  oh-so-common remote exploit, httpd's known bugs, etc.

I don't think a code example is neccesary. How about just some anecdotal
examples?

>  Section e. Application Hardening

This should be moved up to one of the first things. After all, this is
what will make this document different.

> BTW: Apologies for the LARGE post, but it was needed....

I am running short of time, so I will print this email and read it more
closely at home. Comments to follow soon.

-- 
Archaic

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."

- Benjamin Franklin, Historical Review of Pennsylvania, 1759.

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