Re: Secure Linux From Scratch

On Sun, Dec 14, 2003 at 11:21:15AM +0000, Ken Moffat wrote:
> 
> A lot of my boxes aren't patched for the kernel exploit in brk(),
> because it is at base a local exploit.  The old risk / benefit
> continuum.

Yes, but local can quickly become remote if you have telnetd or sshd
running. I assume many of the sections in the book would be skipped by
some, just like many skip the KDE section of BLFS. It's still a matter
of choice built around a core framework. That is what makes the entire
LFS concept so beautiful.

> 
> True.  Of course there is no _guarantee_ that LFS releases work as you
> move further from known environments (particularly, known hosts), and
> the sort of people attracted to LFS _will_ deviate from it.  More
> importantly, does this mean that SLFS will always lag some weeks behind
> LFS releases ? (I'm thinking of the "pattern" in kernel 2.4.23 where
> problems (iptables, the oom-killer,...) only became common a week or so
> after the release.

Of course, at times there will be lag, but the linking of the SLFS
version to the LFS version doesn't mean packages have to stay the same.
Taking your kernel example. The SLFS-5 book would assume a base LFS-5
install. Therefore, the kernel section would say get 2.4.23 and apply
the relavant patches, etc, because if assuming an LFS version, we _know_
the reader has a vulnerable kernel. All changes of this sort could be
numbered by patch-level increments in order to maintain the numbering
cohesion to the LFS book. Example: LFS-5.0 and SLFS-5.0 are released. A
kern bug is found. SLFS fixes it and increments to SLFS-5.0.1, 5.0.2,
etc. Eventually becoming 5.1 when LFS does. Also, all attempts would be
made (just like in BLFS) to keep CVS synced with changes to LFS-CVS.
BLFS had to keep OpenOffice instructions synced to what LFS-CVS was
doing).

>  The big question is, do we have people with enough knowledge and time?

Knowledge, yes. Time, that varies. I know Ryan Oliver and Tushar
Teredesai have shown interest in supporting this, and those of us who
follow lfs-dev know their track records. :) If it's to get off the
ground, we need more developers. Gerard has seen this and is
contemplating it now. If he decides, he may post an RFC to other lists
to see what support is out there. My fear is that this list doesn't have
as many possibly interested developers subbed to it as lfs-dev.

> Code audits are fine as a concept, but the entry barrier tends to be
> high.  OTOH, I'm hopeful that we can achieve this.  Looking at the
> various LFS lists recently suggests our base is becoming wider.  I'll
> watch for anything where I think I can usefully get involved.

Running stuff like bfbtester doesn't require as much knowledge as it
does processing power. Just like proof-reading and submitting SBU times,
the need isn't necessarily guru's, just people willing to help where
they can.

-- 
Archaic

"Those who make peaceful revolution impossible will make violent
revolution inevitable."

- John F. Kennedy

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