Re: Secure Linux From Scratch

On Sun, Dec 14, 2003 at 07:25:21AM -0500, [email protected] wrote:
> Option 2 would be harder for the reader to follow. If some packages are 
> skipped the reader would have to follow two books to do a new build. 

That's why I posted both. To get ideas. :) I don't envision the book as
one that creates an OS, but rather one that modifies one. Therefore it's
an addendum to LFS, with different goals. Option 2 is more like BLFS,
where the reader can pick and choose what things he will do and what
things he will skip.

> Recap some book ideas:
> Pax, openwall, and grsecurity kernel patches. These provide a wide variety of 
> data privacy, and obscurity. Making the system slightly less prone to 
> attacks.

Yep. Pretty easy to implement, too. :)

> Gcc, binutils, glibc support for -fpie/-pie, -fbounds-checking, 
> -fstack-protector, and libsafe. To take advantage of pax at the toolchain 
> level, auditing, and proactive runtime checks.

Is libsafe being developed anymore? There is a lot of overlapping goals
in propolice, libsafe, and the kernel patches. This is where an
organized group of testers come in. Perhaps not all are needed to
achieve the same thing? Perhaps some incur more penalty than others?
It's hard for one person to figure all this out.

> Suid binaries should all be built static. For that matter I think everything 
> in /bin and /sbin should be built static. This is so / and /usr can be 
> seperated properly without anything on / depending on /usr/lib.

IIRC, the LFS method does allow for /usr not being mounted. That's why
libs are moved around and symlinked. As far as building all SUID bins
statically, that's a perfect topic for discussion if the book becomes a
reality.

> Some things should be done about cutting down suid binaries. Maybe hardcode 
> some uid's which cannot use suid programs, and log it if they do (like if 
> user sshd tries to use passwd). Might help, might not.

On my home system, I have only ping, su, passwd, xterm, and XFree86
running suid.

> Also check into privlege seperaton for anything that runs as root,
> including updatedb, syslogd.

Syslog can run as another user (with a patch).

> Have an /etc/login.conf reflect what limits these users can have. I
> think selinux, and others, have special access controls in the kernel
> for special users like this. Maybe the syslogd user should be in a
> chroot on a read-only empty device, since it can be accessed by
> network.

All daemons running remote services, and most daemons running local
serveics, should, IMO, be run in chroot, because all of them are
vulnerable. It's just a matter of time before someone figures out how to
exploit them.

> Maybe have advice for editing limits.h in the kernel.
> 
> None of the above would be noticable to a "user", just to the administrator 
> and system builder. And excpet for -fbounds-checking there would be a fairly 
> small preformance impact from pax, propolice, static /, and -pie, I would 
> guess 2-5% loss from extra cpu and seek time, maybe less.

It sounds like you have a wealth of ideas. Many are ready to go as-is,
too. This is why I think a book like SLFS is so important. It takes
forever to research security topics because of how scattered the
information is. A consolidated repository of these things would benefit
LFS'ers immensely.

-- 
Archaic

The politician attempts to remedy the evil by increasing the very thing
that caused the evil in the first place: legal plunder.

- Frederick Bastiat

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