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