Bennett Todd bet at
Tue Dec 30 08:36:02 PST 2003

I probably missed the backstory somewhere. What's the intended scope
of this list?

LFSes tend to be beautifully hardened compared to alternatives,
since they tend to have minimal services. When someone must
explicitly choose to build and install each service, they don't tend
to install a lot of services they don't care about.

My normal approach to hardening normal systems is along the lines
of "lsof -Pni", then disable or delete every daemon provided by the
distro that's listening on a network socket.

Another layer consists of hardening the system at the shell level
--- attempting to be able to support untrusted shell users,
preventing them from attacking other users or raising their privs.

That's tougher. Again, LFS scores well since with only minimal
needed packages, you've got fewer unnecessary suid executables. On
the other hand, hardened shell servers place the highest demands for
aggressive updating, so software packaging, absent in base LFS, is
more important.

The audit for hardened shell servers consists of searching
all mounted filesystems for suid/sgid executables, and
group-or-world-writeable files and dirs (group-writeable w/
traditional everybody-is-in-one-group systems, not Red Hat's
group-per-user). Then you make sure apps are patched up to date
against tmpfile race conditions, and kernel is patched up against
e.g. the recently-announced do_brk.

Another layer consists of adding sandboxing-style technologies;
selinux is prominent these days, but RSBAC has been around for a
while and it also looks good. In any case, you've got to do some
configuration, but it enables finer-grained access control than the
usual Unix permission model.

What sort of hardening are we talking about here?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the hlfs-dev mailing list