In message <20010723.18091800 at usb.cafod>
Bruce Richardson <brichardson at lineone.net> wrote:
> 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.
<fx: engages brain before posting>
It's *exactly* this sort of expertise that I keep seeing "waved
around" on the 'net: people who have been through the whole bitter
process, and know how to do the job properly from hard-won
experience. I am concerned that what usually happens is, by the time
you have got to that level of understanding, the *last* thing you
want to do is to explain it to someone else, and so it becomes
*very* hard for those of us at the other end of the slope to get to
the top of it without the same bitter and twisting experiences.
Classic examples from elsewhere: the VMS clustered filesystem, and
the entire field of cybernetics.
<fx: brain coasts>
> 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.
And let's not mention default DHCP behaviour.
> 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.
And, returning to the non-offensive half of my original post, I
mentioned the "harden" packages for Debian, which appear to aim in
this general direction. I was kind of hoping that you were aiming in
the direction of producing a cecklist that could be made into
another (or merged into an existing) harden...
Mind you, the very package name will cause enough amusement.
apt-get install harden-bruce anyone?
> 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.
Some problems you don't notice, because you just don't see them.
talkd and fingerd are only security holes when they are broken,
ISTR. *if* the particular implementation of them is non-broken, they
aren't holes. So, for *most* people, talkd and fingerd are not
problems, because they've not been through the broken-glass
experiences that your more bitter sysadmin has been through. Whereas
it's obvious how the utility for breaking your boot sequence
is a security hole :>
Me, I figure that running behind a deny-all firewall with dynamic IP
addressing on dialup means that the network is secure enough that I
can use NIS internally, and even rlogin's from time to time. But,
then again, I also know that anyone who wants to break security on
the system will just enter the building, open the case, clone the
hard-drive, and leave again. So my security model is different. But
given the chance to look at and install a seasoned set of security
enhancements, I do so: as long as it doesn't require me to spend a
week chasing the stuff down... Hence the original comment about
making security tips widely available.
cheers,Rich.
--
Rich Walker: rw at shadow.org.uk (Shadow Robot Project)
http://www.shadow.org.uk 251 Liverpool Road
+44(0)171 700 2487 London N1 1LX
"Sometimes after an electrical storm I see in 5 dimensions"
-- Cornfed Pig, Duckman.
--
Gllug mailing list - Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug