[Gllug] Code Tux

[Bruce Richardson]

On 7/23/01, 3:30:31 PM, Rich Walker <rw at shadow.org.uk> wrote regarding 
Re: [Gllug] Code Tux:

> In message <20010720232111.A26238 at knossos.bruce>
>           brichardson at lineone.net (Bruce Richardson) wrote:

> But I'm still curious: your hard-won notes on how to harden linux
> systems are available somewhere other than the RedHat mailing list,
> aren't they?

No, I didn't do much hardening when I was using Red Hat (Dean, stop 
giggling). I was still learning my way up through the basic utilities 
etc.  Tackling silly X config scripts is a lot simpler than network 
security.  It's only recently that I've felt confident enough to say 
that I can make a networked box acceptably secure.  

Which is part of my point.  MS products may have a poor security 
record but a typical Windows installation is less vulnerable than a 
default Linux set-up (from the major distributors, anyway) - the Linux 
box will be running a large number of powerful and vulnerable 
services, while the Windows box will be running Mr Magic Wizard Is 
Here To Annoy You.

I hope my cfengine article will be interesting but cfengine isn't the 
solution to Linux security.  It's a bolt-on, enabling the 
user/administrator to run round turning things off.  Making a 
distribution safe means implementing security policy throughout and at 
the core of the design.  Each package with security implications 
should install itself according to a security policy and to the 
security options chosen by the machine's owner/admin.

This isn't rocket science.  Debian, for example, has the debconf 
utility, which remembers admin preferences for packages.  When a 
package is re-installed or upgraded it may check for these stored 
preferences - or for the settings of related packages.  All that is 
needed to add security policies to Debian is to create a virtual 
"Security" package and attach a set of security options to it.  Then 
any other package being installed could check those settings and make 
appropriate adjustments.

Defining the policy would doubtless be a flame-fuelled business, given 
the way Debian's loose democracy works.  One a policy was agreed, 
though, the work required would not be huge, as each package 
maintainer would only have to make the adjustments relevant to their 
own package.  Given that Debian already provides a set of core tools 
which many packages use to ease installation, many packages wouldn't 
need to be adjusted at all, as the core installation tools could 
implement security transparently.

There was a huge flamefest on the developer lists about whether the 
mbr package was a security risk but nobody seems to be bothered about 
having talkd and fingerd installed by default.  This puzzles me.

-- 

Bruce




-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug