Subject: Re: why use Amanda? (was: FYI: upgrading GNU tar)
To: Dan Melomedman <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 10/15/2002 13:07:22
[ On Tuesday, October 15, 2002 at 12:41:00 (-0400), Dan Melomedman wrote: ]
> Subject: Re: why use Amanda? (was: FYI: upgrading GNU tar)
> Greg A. Woods wrote:
> > > That is if you trust everybody on your LAN. There have been holes in
> > > AMANDA.
> > If you don't trust everyone on your LAN then you can't use rmt either so
> I never said RMT was better.
This discussion is/was about RMT vs. Amanda for network backups. No
other alternatives have been mentioned (outside rsync and rdiff-backup
which don't really provide their own transport, at least not for
purposes such as this, but use something like SSH instead).
> My point is .*hosts type authentication and
Both plain rsh-style security, as well as the more specific
~/.amandahosts security, is quite sufficient on a trusted LAN between
Unix-style hosts, especially in conjunction with reserved TCP & UDP
ports and a properly deployed internal DNS.
But of course that's not the only kind of security Amanda offers
either. Amanda has had support for Kerberos for quite some time now.
> the fact that you could abuse AMANDA to give you any file you want -
> which is the exploit I was talking about.
Then you haven't configured your Amanda installation properly. The
major security holes related to amrecover were fixed well before 2.4.1.
NetBSD's pkgsrc modules for Amanda are now at 2.4.2p2, and 2.4.3 was
recently released. See the file "docs/SECURITY" in the release.
> It's a good idea, however the software should be secure in the first
> place to disallow exploits from the public LAN such that creating
> private LANs is not necessary.
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.
> Some day I'll just have had it with it -
> and simply run software which was _designed_ for/with security in mind.
> Which excludes AMANDA.
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.
> 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
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>