Re: Secure Linux From Scratch

Ken Moffat <[email protected]>
Newsgroups gmane.linux.lfs.security
Message-ID <Pine.LNX.4.58.0312141056260.18795@ppg_penguin>
On Thu, 11 Dec 2003, Archaic wrote:

> On Tue, Dec 02, 2003 at 08:04:45PM +0000, Ian Molton wrote:
> > On Tue, 2 Dec 2003 13:00:09 -0500
> > "Frank R. Wesselmann" <[email protected]> wrote:
> >
> > > A guided approach to hardening an LFS system would certainly be much
> > > appreciated, so SLFS would be a great book to have.
> >
> > seconded.
>
> WARNING, I'm currently heavily medicated and my thinking is a little
> fuzzy. :)
>

These things are relative.  I can still remember "reading" a display on
the ceiling of the hospital ward when I was on morphine, when the only
computers in the area were the life-support monitors.  This sounds
reasonably lucid to me.

> Okay, if it's going to become a reality we need to start formulating a
> plan of attack. The first one I would consider is book goals and
> format/layout.
>
> I believe the goal of LFS is the way to go. That is, that the purpose of
> the project is to create a book that teaches, not an operating system.
> The end result provides an OS, but learning should still be the main
> objective.
>
> As far as layout, there's two main ways I see:
>
> 1) Write a book the builds a new system from scratch.
>
> PROS:	Less compile time
>
> CONS:	Duplicates a vast majority of the LFS book. (Harder to maintain)
>
> 2) Write a book that systematically goes through all the packages in an
> LFS system and configures them or re-compiles them as needed. Many
> packages won't be touched as they don't have security-related options to
> configure.
>
> PROS:	Smaller book, little duplication
>

Also, this (if you mean add-on instructions for each package) seems a
more practical way to go.  Of course, the first hurdle is always
understanding the issues.  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.

> CONS:	Longer compile times (can be overcome by using links in the LFS
> book that reference the SLFS book much like it currently does for
> hints).
>

I was starting to think we were supposed to _like_ longer compile times
(in excess of 21 hours for LFS-5.0 itself on my test box) ;-) .  In
reality, pure lfs shows that saving the odd hour saved is worth nothing
if the results aren't up to scratch.

> I also think an SLFS book version should strictly match an LFS-book
> version.  This fits well with layout #2 and allows for better testing
> and easier problem solving. Of course, one could use more recent
> packages, but there would be no guarantee to the casual reader that it
> would work.
>

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.

> I really hope to see some replies of interest to this as I think it is
> something that many people can benefit greatly from. The learning curve
> for security issues is high as it is and is only exascerbated by the
> fact that there is a lot of outdated (or just plain wrong) information
> floating around. The creation of a practical, ready-to-use repository of
> security information would be useful for the simple home-system, up to a
> network of production servers. Granted, the book can't teach everything,
> but it can sure teach some practical principles while building a more
> hardened system. Just like with the LFS book, the end of the book is not
> the end of the journey, but rather the beginning.
>
>

 The big question is, do we have people with enough knowledge and time?
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.

Ken
-- 
I'm as free as a bird now, and this bird you cannot chain.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.