Re: Secure Linux From Scratch

On Sunday 14 December 2003 06:21 am, Archaic wrote:
> 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.

I have a 400Mhz Pentium 2, 386MB, 33GB and a  1.3Ghz VIA Samuel 3, 128MB, 
30GB, both of these systems just sit around and do nothing, If someone will 
coach me about bfbtester I can try to run it, and/or I am willing to try 
testing patches on sidefects. My 256KB cable modem has a pretty constant IP 
so I could host files.

Class is out for a 2 week Christmas so I am going to build a base LFS-5.0 
system during that time, to use for what ever.

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