I am interested in working on getting
https://labs.riseup.net/code/issues/5301
"Clone or Backup Persistent Volume" implemented. My current process is to just
make an encrypted tarball as root while offline, but that's a real pain
because there are lots of times I want to get a backup of something important
(like a new key) as quick as possible as to prevent loss, and I don't want to
be enabling root all the time just to make backups.
I'm wondering if my plan would be considered insecure under the current threat
model, however. I was thinking about adding new steps into
tails-persistence-setup for backing up the tails persistence partition into an
encrypted tarball, and then another one for restoring persistence from a prior
backup.
The backup step would ensure that persistence has been enabled and mounted,
and then go into /live/persistence/TailsData_unlocked/ then run something that
would be the equivalent of something like this
tar cjf - . | gpg --cipher-algo AES -c - > /home/amnesia/YYYY-MM-DD-backup.tbz2.gpg
then test it with something that does something like this
cat /home/amnesia/YYYY-MM-DD-backup.tbz2.gpg | gpg - | tar djf -
If that gives outputs anything, we give some sort of abort/retry/fail message
to the user. If all goes well, then the user has a file they can back up
with a secure method.
The restore step would do the current delete partition steps (if there was
already a persistence partition found) , then most of the current steps to
create a partition, but instead of asking the user what they want to use their
new partition for, it would instead ask the user to pick an encrypted backup
file and would untar it into the directory that the partition was mounted
for initialization.
Does anything look bad with this plan?
CustaiCo
