Re: Secure Linux From Scratch

On Fri, Dec 19, 2003 at 02:29:56AM +0200, Christos Gioran wrote:
> 
> But my "problem" lies within the fact that a secure system must be
> build as one, not as an LFS with "security changes" i.e. to simply
> choose what to secure.

SLFS should, IMO, be a spearate book that systematically goes through a
freshly built LFS, and hardens it. If someone decides to skip a section,
that's on them, not the book. It would be an unneccessary hassle to try
and create a book that is a duplicate of LFS, with only the minor
security enhancements. LFS provides the base, BLFS provides an
extension, and SLFS can provide hardening of those two books. 

One thing that many people may not understand (assuming that by some
comments I've read) is that this book is *NOT* intended to be a
replacement of LFS or BLFS or any given sections of those books. The
biggest reason for this is that many security enhancements cause loss of
performance and/or convenience. Therefore, we need to strive to document
what loss of features/convenience/performance, is any, will be incurred
by any given hardening procedure. Remember, the goal should be teaching,
not creating a secure system. That is only a by-product. And many may
find that by-product unacceptable for their particular uses. For
instance, if we were to write a hardcore, do-it-this-way-or-suffer book,
then the section on X would look like this:

Xfree86 (and it's relatives)
DON'T EVER INSTALL!

We need to remember that the right balance of security and features
depends on the user and note heavily the possible consequences of both
applying, and not applying, any given procedure.

> someone installs libsafe only (since it is easy and doable at any
> time) and skips the propolice patches as a hassle. BINGO, this user
> has a false sence of safety, thinking that he protected his/her
> system. Not very educational, don't you think?

Getting rooted can be very educational (though sometimes at a high
price). We do need to make sure people are aware of consequences, but
unless you are paranoid, everyone has a false sence of security.

> The build procedure must follow strictly a security policy that we
> must design. A disclaimer of some sort should be used to explain that
> patching selected pieces leaves the system in danger.

Agreed.

> A local user just resets and boots from a floppy....no matter how good
> a propolice patch is)

Layers of security, my friend. When I had my own business, my servers
had no cd-roms nor floppies. Hardcore is only a matter of perspective.
A good software example is sysklogd. It can be patched to run as a
non-root user. Does that make it good enough? No. It should still be run
in it's own chroot along with every other daemon. I like /opt/httpd,
/opt/sysklogd, /opt/proftpd, etc. Each is run untrusted, and in chroot.
We cannot prevent all exploits. What me *MUST* do, though, is minimize
damage done.

> Could be mentioned, but this subject I think holds the right to a separate 
> list (hopefully, people will join in). HOwever, coordination with the 
> developing brains is in order. We shall see how this turns out.

Yes, that's what I'm hoping for, as well.

-- 
Archaic

Never could an increase of comfort or security be a sufficient good to
be bought at the price of liberty.

- Hillaire Belloc

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