HLFS Fortress <=> 2.4/2.6 Kernels

Peter Ennis peterennis at yahoo.com
Fri Apr 22 12:34:03 PDT 2005


Great thread. Read it three times :-)

My personal summary:
 
>Archaic wrote:
Short of hiring a tiger team, I have tried everything I could to attack a
recent HLFS build...
Security fixes come fast and are often relevant to 2.4 kernels, as
well...
>Sean McLinden wrote:
Well, I wouldn't qualify as a developer, but 
I have build a farm of public HLFS servers based upon kernel 2.6 
and at this point, my decision is to stay with this
>R.Quenett wrote:
I would not expect to use hlfs on a desktop in the forseeable future. 
Period.  Full stop.
>Archaic wrote:
We should define a roadmap with a specific target.
>Jerome Pinot wrote:
My point is we should not go too fast,
and so plan to build around 2.6...
It's all about roadmap, but the use of only one kernel and one libc
seems better to me.
>Jeremy Huntwork wrote:
there will *always* be some aspect of any system that will 
be vulnerable to attack, or exist as a point of failure.
>Mike Hernandez wrote:
The extra time between now and the release date for the book will only be
making the end result better, so it's well worth it.
>Robert Connolly wrote:
The way I see it, linux-2.6 is the only unstable package we have...
I think its best to  take a back seat to lfs-unstable and 
refocus on the security enhancements...
I'm running linux-2.4 at my house because I got tired of following the 
2.6 branch, ... I would like the rest of you to vote on this because
its a fairly serious change
>Archaic wrote:
I have no problems with slowing down. I encourage it.
But I don't think going backwards is the solution.
>Jim Gifford wrote:
the only true secure kernel is the 2.2, which Trustix is using...
My vote is that HLFS should stick to the packages in LFS, with the only 
deviation of patches needed for a secure system
 
My POV:
I would not like to see Robert get developer burnout,
and agree with the problems inherent in making 
a roadmap where roads may not even exist.
 
The comments so far seem to show a strong
conceptual unity and yet display a diversity
in understanding of the end goal.
 
I see it as follows:
 
The book is the roadmap.
The goal is a fortress.
 
Consequently:
1. Fortresses take a long time to build, are
are expensive and static
2. Siege engines are comparatively small,
cheap, mobile, quick to build and of many varieties
3. The success of a fortress is determined
by how well it survives under siege
 
I would like to see a commando assault
team that is dedicated to beating
the c&&p out of the fortress and
tracking the success/failure.
 
Benefits:
1. Developer encouragement (Technology)
2. Understanding the defenses through
knowing enemy strategies (Education)
3. A public track record (Marketing)
 
So...
 
Is there a way to get an HLFS prototype
fortress server LAMP system on-line that
can be assaulted?
Let the hackers of the world be the Tiger Team!
 
Of course, this is only one aspect of HLFS
but it is highly visible and of widespread
public interest (especially 2.6.x kernels).
 
PFE
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20050422/431cda2d/attachment.html>


More information about the hlfs-dev mailing list