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