>>>>> On Mon, 01 Jul 2013 15:25:23 +0200, Jérôme Blion said:
> 
> Le 2013-07-01 13:07, Martin Simmons a écrit :
> > Bacula does have root read (and write) privileges on every backed-up 
> > system,
> > but you can encrypt the backups before sending them to the central 
> > server.
> > Bacula can also sign the backups, so the client can verify that a 
> > restore
> > doesn't contain modified data.  You still have to keep the 
> > encryption/signing
> > keys secure of course.
> > 
> > __Martin
> 
> 
> If the bacula server is compromised and the attacker gains root 
> privileges on the Bacula director, it can modify any client's job to run 
> a specific command to gain access (unprivileged or not)
> In this kind of architecture, securing the director from unauthorized 
> access is primordial and needs to take the necessary time to do it 
> properly.
> 
> If you don't grant privileges to clients (console access and so on), 
> they can be safely compromised (sigh). At worst, you will back up wrong 
> files. If they have a console access to the director, you must ensure 
> they can't do harm to your system or your files (restoring files from a 
> confidential system on a public one, for example)

The latter case is secured by encrypting the backups (since the key is only on
the correct client).

You are right are the risk of compromise of the client though -- it looks like
there is no way to force the FD to only restore from signed backups.

__Martin

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users