archaic at indy.rr.com
Tue Dec 30 08:50:38 PST 2003
On Tue, Dec 30, 2003 at 11:36:02AM -0500, Bennett Todd wrote:
> I probably missed the backstory somewhere. What's the intended scope
> of this list?
For the whole story, you should read the lfs-security archives for
December. However, to save you some time, read the archives of this list
(archiving is done in near-real time). You will see the half dozen or so
emails posted before you subbed.
> LFSes tend to be beautifully hardened compared to alternatives,
Not running a service doesn't mean hardened. We aren't concerned with
only services and privs, but also the underlying toolchain. We will be
patching to avoid many "types" of attacks before exploits even exist. If
nothing else, it may give someone a little more time to upgrade a
package. Also, we will explain how to log remotely and how these
patches will cause many attempted exploits to be logged even when they
don't succeed, giving the admin more information.
> 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 isn't necessarily proportional to the number of services you
have running. IOW, your system can be compromised just running clients,
with no servers at all.
> 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.
That's definately a start, but you can't really fix the inadequacies of
a distro simply by configuration. To achieve any real modicum of
security, you have to start with the base system.
> 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 another brick in the wall. There are many. And you can't place
the 2nd brick until you place the 1st. And you can't (or at least
shouldn't) place the 1st brick until you've laid a foundation.
> 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.
We will be going beyond the base LFS packages.
> 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.
There a lot more to it that that.
> 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.
We are still investigating those as well as grsecurity (which has
implemented RBAC, too). I tend to shy from selinux from the get go,
because of possilbe licensing restrictions. It is gov't property, after
> What sort of hardening are we talking about here?
All the above and then some. Wanna help? :)
Of all tyrannies, a tyranny exercised for the good of its victims may be
the most oppressive. It may be better to live under robber barons than
under omnipotent moral busybodies. The robber baron's cruelty may
sometimes sleep, his cupidity may at some point be satiated; but those
who torment us for our own good will torment us without end, for they do
so with the approval of their consciences.
- C. S. Lewis
More information about the hlfs-dev