Hello Matthew, thank you for your contribution. Currently I'm not aware of any users, requesting a feature like this. Anyhow, I like the idea (even so I don't like changing the tape and block format).
The Bareos project has regularly core developer meetings. I'll put your proposal on the agenda of the next meeting beginning of December, to discuss this feature internally. We will give feedback afterwards. Regards, Jörg On 24.11.18 at 19:25 wrote Matthew Ife: > Hi, > > Its been a while since I did anything serious with Bareos in terms of > development (I wrote the client quota support for bacula a long time > ago) but had a idea I wanted to make work recently and spent a week > doing the first draft of it. > > Attached, I've patched in in-format support for encrypted volumes. I > consider it a first draft to prove it can be done and I reckon is > pretty shakey at the moment. > > I do intend on being backwards compatible with older volumes of course. > > Currently I dont think its really elegantly written, offering good > debugging output or providing suitable diagnostic information. > > It works in the volume formats block layer rather than as a device > backend - providing support for all future storage backends. > All data after the block header (except block 0) is encrypted. > > I wanted this feature for a few reasons. > - dm-crypt works but only does at-rest encryption. > - Some tape systems dont do encryption. Would be nice to be able to > supply it. > - I dont need the client side management overhead using record > encryption yet it would still be definitely nice to protect the volumes > data some way. > - Its not so simple to make a mount command with dm-crypt devices > without raising bareos privileges in some way. > > My personal inclination is actually to be shipping volumes off to > MicroSD cards (cheap, portable and removable) which is what I want to > be using it for. > > I was originally going to do this using a device backend, but it turns > out thats really quite tricky where theres no good guarantees on how > much data will be requested on a per-block level. Thats needed for > checksumming. Given the block structure provides it, it works best > there. > > The first issue I can see is my implementation is its quite invasive. > > 1. I bumped the bacula volume label version number up to 21. > The volume label now carries a 'Salt' parameter (an 8 byte random > nonce) which is used in a password key derivation routine. > The volume label also carries a 'Cipher' parameter, a unsigned short > which denotes the crypto cipher used to encrypt the volume. I've only > implemented AESGCM-256 and NONE (the default for older volumes and non- > encrypted volumes). > > 2. I bumped the bacula block version up from v2 to v3. It now carries > the readable value 'BB03' instead of 'BB02', the block headers are > increased by 32 bytes in size and carries a cryptographic checksum of > the block it protects. This could be 16 bytes but I'm thinking ahead > for other crypto ciphers. > > Secondly another obvious issue is I dont feel the code follows any > standards specific approach used with Bareos at the moment. Its using > OpenSSL without any abstraction in place. I suspect ideally the lib > folder should actually apply the heavy lifting in this case by moving > the OpenSSL/EVP stuff I use into that path. > > As I said, I do have a proof of concept implementation that appears to > work but quite honestly needs a LOT more testing and checking to make > sure it deals with anomalous situations (such as end of media halfway > through a block write). > > Before I pursued this project further I wanted to get some idea if > there is any value in this code ultimately being merged upstream and if > me changing the on-disk format gives people the wigglies :). > > If the feature is desirable I'll redraft it to behave more in line with > bacula libraries doing the lifting and shifting of the crypto. Also add > more diagnostic output. > > After patching, its enabled by adding the parameter: > > Volume Crypto Key = "My super secure secret password" > > To the Device resource in bacula-sd. > > If you write out a backup using this format it can be read out again > transparently decrypted using bextract and bls, providing you have the > device resource setup. > > The patch is applied against the latest git clone of the repo. > > Thoughts welcome. > -- Jörg Steffens joerg.steff...@bareos.com Bareos GmbH & Co. KG Phone: +49 221 630693-91 http://www.bareos.com Fax: +49 221 630693-10 Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646 Komplementär: Bareos Verwaltungs-GmbH Geschäftsführer: S. Dühr, M. Außendorf, Jörg Steffens, P. Storz -- You received this message because you are subscribed to the Google Groups "bareos-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to bareos-devel+unsubscr...@googlegroups.com. To post to this group, send email to bareos-devel@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
