On 12 Feb 2006 at 13:49, Landon Fuller wrote:
> Dan Langille wrote:
> > On 5 Feb 2006 at 18:33, Landon Fuller wrote:
> >
> >
> >>In the spirit of status reports -- Bacula's File Daemon now has complete
> >>support for signing and encryption data prior to sending it to the
> >>Storage Daemon, and decrypting said data upon receipt from the Storage
> >>Daemon.
> >
> >
> > Now that's pretty cool!
>
> Thanks!
>
> > How does it work? Just simple public key encryption type thing?
>
> Right - a session key is randomly generated for each backup job, and
> that session key is then encrypted using "recipients'" public keys. By
> specifying multiple public keys, one can specify multiple recipients
> that may decrypt the backup.
Multiple decryption keys is a nice feature.
> The downside to the current implementation is that a copy of the
> encrypted session keys is saved with *every file*. The size of this data
> structure isn't huge, but it does add up. If I recall correctly, with a
> single 2048 bit key the on disk structure was ~280 bytes. For 100,000
> files, that adds up to 26 megabytes.
100,000 files is a big backup anyway. So another 26MB isn't much.
I'm backing up to DLT 7000... 26MB is less than 1% of a tape.
> I'm not sure how much of an issue this is for potential users of FD-side
> data encryption. The upside is that the backups are much more resilient
> to tape/disk corruption.
I think it's pretty minimal. The first time they get a bad spot on a
tape, they'll be glad to have it.
> As far as generating the keys, I'm just using self-signed PEM encoded
> x509 certificates and private keys. They be generated with a couple
> openssl(1) one-liners.
>
> One other issue worth raising -- The director can currently overwrite
> any file on the FD, including the encryption keys or the FD
> configuration file, thus exposing private data to the director.
Overwriting is not something I'd thought of. Perhaps it's time to
come up with some FD-side restrictions:
Protected {
NoAccess = /path/to/my/keys
}
This is a directory level directive. The FD will neither read nor
write anything under that directory. This cannot be overridden by
the Director.
> I thought that we could solve this by either:
> 1) Provide a "Allow Restore" flag that allows one to disable
> restoration until it's actually needed, or
> 2) Provide a "Restore Root" directive that allows the specification
> of a restoration root under which all restored files must live. I prefer
> this option, but 1) is certainly easier.
I like #1. It allows a user to have confidence that files cannot be
updated without their knowledge. #2 means that the FD specifies the
"Where" parameter that we see in the restore command. The DIR would
not be able to override this parameter.
> > I've been using the TLS feature for a few weeks now. I'm pretty
> > happy with it. It's been working every time withojut fail. No more
> > stunnel for me.
>
> Glad to hear it. We've been using the TLS implementation ever since the
> tail-end of the 1.37 release cycle, zero problems. One feature I'd
> really like to see is the implementation of SSH-style public key
> validation -- caching the public key on first connect and then
> validating against the cache. It'd be a nice alternative to maintaining
> x509 infrastructure. I don't know when I'll have time to tackle the
> problem, but if anyone is interested in the project I'd be happy to
> provide some pointers. It's not too hard to do ...
SSH keys would be a nice option, I agree. Many people are familiar
with SSH keys and it's one less thing for them to learn.
--
Dan Langille : Software Developer looking for work
my resume: http://www.freebsddiary.org/dan_langille.php
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
