Amanda-Users

Re: Amanda Security

2005-04-14 08:10:04
Subject: Re: Amanda Security
From: Greg Troxel <gdt AT ir.bbn DOT com>
To: Paul Bijnens <paul.bijnens AT xplanation DOT com>
Date: 14 Apr 2005 08:01:39 -0400
Paul Bijnens <paul.bijnens AT xplanation DOT com> writes:

> Greg Troxel wrote:
> > d) Can an unauthorized party ask the server to retrieve backups?
> > I'm not the least bit comfortable with this; I don't run the recover
> > or indexing daemons.
> 
> This part works also using bsd-security.  The .amandahosts file
> works both ways.
> 
> The .amandahosts file on a client contains the host and username of
> amandaserver.  It is usually only one line on most clients:
>    server.nowhere.com   amanda
> 
> The .amandahosts file on the server contains usually the same line
> (because the server is a client of itself too).  And in addition to
> this, you can/need add a line for each client that needs to
> recover files.  That line usually needs to specify "root" as username,
> because you usually want the permissions and owners of files on the
> client to be correctly restored too.

It would be nice to have a different ACL file for client retrieval, so
that "retrieve backup" and "do backup of server" privs can be granted
separately.

It would be cool to have a way to specify limiting retrievals to the
host for which the backups are, i.e. clientN can only retrieve
clientN's backups.

Perhaps in the head branch where there is gss-api support amrecover
could authenticate/encrypt and have per-host and global retrieval
acls.

> When I need to restore on a client, I can uncomment the necessary line
> for a few minutes/hours.

That makes sense - good application of the Principle of Least Privilege.

> (*) real comments are actually not supported in the syntax of the file.
>      The program assumes the hostname is '#client1.nowhere.com'
>      which, if you control the DNS access on the server, does not
>      match any existing hostname.

It would be nice to add these; it would avoid having to analyze the
DNS situation to be comfortable.  But on NetBSD 2.99.15, ruserok(3)
does not seem to ignore lines with #.

-- 
        Greg Troxel <gdt AT ir.bbn DOT com>

<Prev in Thread] Current Thread [Next in Thread>