>>>>> On Tue, 02 Jul 2013 13:46:02 -0400, Josh Fisher said:
> Authentication-Results: mail.pvct.com; dkim=none reason="no signature";
> 
> On 7/2/2013 11:03 AM, Martin Simmons wrote:
> >>>>>> On Tue, 02 Jul 2013 08:32:43 -0400, Josh Fisher said:
> >>              Using PKI data encryption together with the ability to
> >> disable scripts would allow for fairly safe restores, since the FD's
> >> private key would be needed to alter any files being restored and a
> >> compromised Dir could not run commands to alter the FD's private key
> >> even when FD was running as root.
> > Unfortunately, I think that still isn't secure because the FD doesn't 
> > enforce
> > encryption and signing is only checked after restoring the file (too late).
> > Also, it doesn't have a way to check that the file is restored to its 
> > original
> > location.  Finally, I think file attributes are not encrypted or signed so a
> > malicious restore could change the permissions on a file even if it couldn't
> > read the data.
> 
> Are you saying that if the FD has PKISignature=yes that it will still 
> accept and restore a file with a bad or no signature? If, so then isn't 
> that a FD bug? If the FD is configured to use signing, then it should 
> not be possible to restore a file with a bad signature. I agree with 
> you, though. Bacula's PKI data encryption is incomplete.

It looks like it will complain about bad or no signature, probably stopping
job, but this happens after the file has been written to disk.

__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