Add backup solution

[keyctl]

We need to backup essential data of our system.

Two ready solutions seem "practical".

• Borg
• restic

Also, there exists Burp, which even supports pushing backups. However, we might not need pushes for backups, if we manage to backup generated private keys separately.

[keyctl]

@Liblor If you need help with setting up Borg, I can help.

[Liblor]

A drawback of pull solutions is that if the backup server gets compromised, the adversary has access to the other servers. One could argue that it is not very likely that only the backup server gets compromised, but since we would have to add a separate solution for the private keys the attack surface of the backup server is extended.

[keyctl]

@Liblor Wait, Borg is push, or am I confused?

[keyctl]

In my setup, each server pushes their backup with borg create. I think I got this confused before. So push is actually what we want to use, which means we don't need to backup the private keys separately.

@Liblor If you want, I can propose a base for this issue, and let you refine it?

[Liblor]

Ah, I thought you said that borg was pull (2 weeks ago?)... Sure if you have a good base setup, I'm happy to work with it

[keyctl]

Sorry, I got that wrong, apparently just realized how my setup works ;-)

[keyctl]

I'll get back to this soon.

[keyctl]

@Liblor I pushed something into the branch backups. I hope it will be useful.

[keyctl]

There's some more stuff todo. Most importantly, I did not test it, as it is not functionally complete. We'll have to setup repositories on the backups servers for the hosts. These are protected by keys, which are generated during settings these repositories up. I'm not sure how to retrieve those programmatically. The keys should be stored in the script directory and named borg.phrase.

[Liblor]

Yeah, I read (parts of) the documentation so far. I'll work on it now :) thanks

[Liblor]

Hm, we still have to implement a separate feature for the private keys backup... Borg allows a user to see his/her old archives, that is exactly what we don't want for the private keys without passphrase!

[keyctl]

I know this is optimal from security perspective, but it's not used in practice a lot because you cannot compress the data. So in terms of practicality, I don't think there is a solution to have asymmetric encryption.

[Miro-H]

Would it help if I tried on the CA to encrypt the private key with the backup servers public key before pushing it?

[Liblor]

I know this is optimal from security perspective, but it's not used in practice a lot because you cannot compress the data. So in terms of practicality, I don't think there is a solution to have asymmetric encryption.

True, you couldn't do delta backups and stuff... We don't backup a lot of data, so it wouldn't be a big issue for us, but I see why other solutions are not prominent. There are only a few use cases where the backup client shouldn't be able to see its backups.

Would it help if I tried on the CA to encrypt the private key with the backup servers public key before pushing it?

Yes, that should work :thinking:

[keyctl]

Right, and from a security perspective we should aim at using software that's well known and widely used, e.g. not too niche. I think encrypting with the public key of the backup server should work, but we need to make sure that the private key is not lost.

[Liblor]

For the report, I'd write that we print the key and store it in a safe.

[Miro-H]

Oh, we need yet another key for the backup server, since we cannot make the TLS key offline.

But ok, then I try to get this to work on the CA.

[Liblor]

Oh, we need yet another key for the backup server, since we cannot make the TLS key offline.

But ok, then I try to get this to work on the CA.

Did you look into this? Because besides this the backup functionality should work on #36. Otherwise I can also look into it.

[Miro-H]

Oh, we need yet another key for the backup server, since we cannot make the TLS key offline. But ok, then I try to get this to work on the CA.

Did you look into this? Because besides this the backup functionality should work on #36. Otherwise I can also look into it.

Not yet, if you have time, sure. But I could also do it soon, in case there are other things like the cluster that you want to work on.

[Liblor]

Oh, we need yet another key for the backup server, since we cannot make the TLS key offline. But ok, then I try to get this to work on the CA.

Did you look into this? Because besides this the backup functionality should work on #36. Otherwise I can also look into it.

Not yet, if you have time, sure. But I could also do it soon, in case there are other things like the cluster that you want to work on.

Okay, in that case I'll work on the cluster first. And then whoever finishes firstly, does the backup of the private keys. It shouldn't be to complicated.

The private keys should be stored encrypted into /home/coreca/backup and then /etc/borgbackup/run.sh can be called to perform the backup.

(this reminds me that I have to create a sudo rule, that allows coreca to call run.sh as setuid doesn't work for bash scripts)

[keyctl]

Closed per #36.