[ On Tuesday, October 15, 2002 at 22:45:02 (-0400), Dan Melomedman wrote: ]
> Subject: Re: why use Amanda? (was: FYI: upgrading GNU tar)
>
> Whether they were fixed or not isn't as important as much as the presence
> of holes at some period in time. The historic record is there, you can't
> ignore it. How much money are you willing to bet there won't be any more
> holes in AMANDA or any other package with a bad record?

Oh, come on now!  I remember a very long time ago when 4BSD had a very
serious bug that allowed users (and rogoue processes) to bump the CPU
limits for all their child processes.  That was a very serious kernel
level security bug (caused by a tiny one-line typo, IIRC), especially
for a student system where CPU limits were used to enforce fair sharing
of a 1-MIP CPU amongst up to 60 concurrent users.  Even 4.4BSD has
endured more (and perhaps more serious) security bugs in the very recent
past.  Indeed there's a very long and rather bad historic record of such
bugs in the code which now makes up NetBSD's kernel.  I wouldn't bet any
money at all that there won't be more security-sensitive bugs in the
NetBSD kernel.

_EVERY_ kernel and software package for unix-like systems will continue
to have the chance of security bugs until the day that they are _all_
written by machines which cannot make mistakes.  Even if all software
were written in languages that make bugs very difficult to create we'd
still have some bugs and so long as we have bugs then some of them will
be security bugs.

Software which documents its historic record of security bugs and their
fixes suggests to me that its authors and maintainers do take such
issues seriously and that suggests there's some chance they've taken
better care in more recent releases too.  I.e. to me that record is a
good record, not a bad record!

You also have to remember that network security is a really fleeting
thing.  Any kind of communications outside of a single trusted computing
base can lead to many security issues.  Sending data over TCP/UDP IP
virtual circuits on something like an Ethernet network simply cannot be
done truly securely without either low-level support in the network
gateways or system kernels for the likes of IPsec, or else tremendous
overhead in the applications themselves for the likes of SSL/TLS.  None
of that kind of protection comes for free -- it's very compute intensive
and the overhead climbs with the amount of data you're trying to push
through those circuits.  Amanda has to push a lot of data very quickly.
Any sane network administrator will provide it with a private path if
security is really of concern.

> > That's just not possible, especially for something with the requirements
> > common to generic backup software, never mind the fact that the general
> > assumption by system developers has usually been that the local LAN is
> > _not_ a public network.
> 
> I can't see why it's not possible. Simple, secure, flexible software is
> available right now even at no cost and with source code available. It
> has been done, there's nothing special about.  Just because the majority
> of software sucks doesn't mean it's impossible.

You're not paying attention to the reason for this discussion.  We're
talking explicitly about backup software, and you've streched the
requirements to a wish for simple, flexible, _networked_ backup
software.  I'm telling you that in the past 20 years or so there's been
no such thing despite the fact that many people have even been willing
to pay _huge_ amounts of money for it.  What they do end up paying their
money for is software that's far from simple to use, and often not even
all that flexible either.  Wishing for such a thing to appear out of the
blue as freeware is really blue-sky dreaming!

> > Amanda was in fact designed with security in mind -- just not the kind
> > of security that makes it safe to run it across a public network since
> > that wasn't a design requirement.
> 
> It wasn't even designed to run securely inside of a LAN - you wouldn't
> see holes otherwise.

I think you should try reading the code, the design and internals
documentation, and perhaps even talk to the authors and try doing a real
analysis of the past errors in the code, before you make more
pronouncements that are so false.

> > > All I'd like to see is a set of tools similar to AMANDA but done right.
> > 
> > We're all waiting for your detailed technical proposal and prototype
> > implementation!  ;-)
> 
> I already have beginnings of a  design for it, but I doubt I'll ever
> have the time to implement it or even publish it. As I said before the
> currently available software is good enough for most people - the
> incentive to write something simple and beautiful is just not.

Although the commercial world doesn't always vote for "simple and
beautiful", perhaps your proposal could gain you employment with a
software firm who would fund its completion and construction.  Then
again maybe if you published what you have now you might inspire someone
who does have the time and incentive to complete it.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>