Robert Day zarin at
Tue Dec 30 08:39:32 PST 2003

On Tue, 2003-12-30 at 11:36, Bennett Todd wrote:
> I probably missed the backstory somewhere. What's the intended scope
> of this list?
Very hard..  As hardened as it can become in our world basically ;)  LOL
We're talking about application hardening, compiler tweaks, library
locking etc. etc.  Check the LFS Security list archives - there are alot
of archived emails there.

> 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.
Security by Obscurity. Remotely secure due to lack of connectivity.
Locally Secure due to lack of software to run. Does not make a secure /
hard server / workstation.. local user can install or code an exploit
source, compile it and become root. Etc.

> 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.
Yes, the user privelage system is going to be an area of focus in the
introductory chapters.

> 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.
Yes indeed. This is part of the plan..  Kernel patches, library patches,

> 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?

Hope the above helps.

  Rob Day (BOFH)

More information about the hlfs-dev mailing list