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.

>
> __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


------------------------------------------------------------------------------
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