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@lists.sourceforge.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
