#568 Issue closed: Backup log contains the BACKUP_PROG_CRYPT_KEY

Labels: enhancement, documentation

davixd opened issue at 2015-03-26 15:14:

Hi,
the backup log contains the BACKUP_PROG_CRYPT_KEY, is it possible to blank it?

My /etc/rear/local.conf:
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://10.0.xx.xx/backup/"
BACKUP_PROG_ARCHIVE="backup_$(hostname)_$(date -Iseconds)_crypt_des3"
GRUB_RESCUE=1
GRUB_RESCUE_PASSWORD="SECRET"
BACKUP_PROG_CRYPT_ENABLED=1
BACKUP_PROG_CRYPT_KEY=”testpw123”

On the target server:
[root@fs-01 rear-backup]# cat backup_rear-backup.xxx.int_2015-03-26T14:50:16+0100_crypt_des3.log
2015-03-26 14:50:37 tar --warning=no-xdev --sparse --block-number --totals --verbose --no-wildcards-match-slash --one-file-system --ignore-failed-read --anchored --gzip -X /tmp/rear.b7bE08LIU8DwWBV/tmp/backup-exclude.txt -C / -c -f - / /var /boot /var/log/rear/rear-rear-backup.log | /usr/bin/openssl des3 -salt -k ”testpw123” | dd of=/tmp/rear.b7bE08LIU8DwWBV/outputfs/rear-backup/backup_rear-backup.xxx.int_2015-03-26T14:50:16+0100_crypt_des3.tar.gz
tar: Removing leading `/' from member names
...

Because nfs use no encryption, it is not a good idea to send the password of the crypt backup true the same line. Is it possible to disable it? Or antoher best practice to do it?

My goal is:
The backup file needs to be encrypted on target and the line secure (rsync or nfs but without sending the password of the backup file).

Many thanks in advance!

Best regards
davixd

schlomo commented at 2015-03-26 15:26:

IMHO full automation and security are always in confict and require some trade off.

The log is not the main problem. The rescue system also contains this password and most likely it lies next to your encrypted archive. In any case, if you want to have an automated restore then the rescue system needs the password.

I can think about some ideas:

  • Use asymmetric cryptography: The key to encrypt stays on the server, the rescue image contains another key that can be used to decrypt the backup.
  • Control ReaR from outside (e.g. an external agent) that provides the encryption/decryption keys on-the-fly without storing it on disk. Maybe the discussion in #522 helps there. Basically you can add ReaR config on the command line without storing it in a file.

davixd commented at 2015-03-26 15:45:

Thanks for the advice/tip! But for me there is no need for such a complex scenario, because I dont need a full automated restore system.

What I have in mind:
encrypt the backup file while or after (on the the source system). Sending the backup file to the target without any password in log or rescue medium. While restoring, the rescue medium have to ask for the password (and password have to be typed in, stdin) to be restored.

Is something like this possible with rear?

schlomo commented at 2015-03-26 15:54:

I think that it can be done, but probably you would need to change something in ReaR or maybe change the way how the password is integrated. Maybe https://www.openssl.org/docs/apps/openssl.html#PASS-PHRASE-ARGUMENTS can servce as a method to allow different usage scenarios with the same code. If you have the password stored in a file that is excluded from backup then you are almost there. Maybe one needs to separate between the backup password and the restore password, the default beeing the same.

In any case, ReaR needs to be extended for this feature. Do you want to provide us a patch?

davixd commented at 2015-03-26 17:23:

Iam new to this project, so I have to find out first, how everything is working together. Before I even didn't know, that the rescue image is saving the BACKUP_PROG_CRYPT_KEY. But sure, when I will have something, I will post the patch for that.

Thanks.

davixd

davixd commented at 2015-03-30 14:56:

I have modified some codes lines, to achieve this goal and its working.

Edit: /usr/share/rear/backup/NETFS/default/50_make_backup.sh

Modify line 43 to: LogPrint "Encrypting archive with a key."
Modfy line 81 to: $(cat $TMP_DIR/backup-include.txt) $LOGFILE | $BACKUP_PROG_CRYPT_OPTIONS BACKUP_PROG_CRYPT_KEY | $SPLIT_COMMAND

With this settings the crypted key don't occur in the logs and is not present in the rescue iso. To recover the key have to be typed it in in /etc/rear/local.conf, BACKUP_PROG_CRYPT_KEY="".

Is there another place where the crypt key is also stored? If not, then the rescue iso and the backup.tar.gz is save to be transported over unsecure lines.

I have tested it successful in basic configuration (backup and recover):
/etc/rear/local.conf:
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://10.0.x.x/backup/rear/"
GRUB_RESCUE=1
GRUB_RESCUE_PASSWORD="SECRET"
BACKUP_PROG_CRYPT_ENABLED=1
BACKUP_PROG_CRYPT_KEY="testpw123"

I hope there are no side effects, I will test it also with extended settings.

schlomo commented at 2015-03-30 15:56:

Great!

Could you please provide a pull request with your change?

Also, could you please make sure that ReaR refuses to start working if the key is missing? Or give the user a chance to type it in interactively?

I find giving users clear guidance an important aspect. Most likely the user doing the restore won't know exactly what was configured years ago.

Thanks a lot!

davixd commented at 2015-03-31 16:02:

Yes, sure, a pull request will come soon.

ReaR is already giving a hint, when the key is missing to type it in in local.conf.
What have to / can be done: Is to make it interactively. I will try it soon.

Is incremental backup supported by ReaR? Cause I tried it with BACKUP=NETFS and there is a problem while recovering grub.

Many thanks in advance!

schlomo commented at 2015-03-31 19:27:

Did you try https://help.github.com/articles/using-pull-requests/?

gdha commented at 2015-05-31 15:44:

@davixd How far are you with the pull request? If I don't hear something soon I'll push this to the milestone 1.18...

davixd commented at 2015-06-07 11:29:

Hi guys,
sorry, but I was very very busy in the last few months.

Here is my pull request:
https://github.com/rear/rear/pull/594

These are the two changes, which have to be made in /usr/share/rear/backup/NETFS/default/50_make_backup.sh, to achieve this goal.

The asking for interactive password is not included yet, but while trying to recover the backup without a password, rear shows a hint in the error message (stdout) to get sure there is a password set in /etc/rear/local.conf.

I hope my pull request is done the right way (my first pull request).

gdha commented at 2015-06-16 11:58:

@davixd Thank you for the pull request - it is just fine.
Just add a label so we do not forget to add proper documentation for this feature.

[Export of Github issue for rear/rear.]