CustaiCo:
> I am interested in working on getting https://labs.riseup.net/code/issues/5301
> "Clone or Backup Persistent Volume" implemented.
Thanks a lot for starting that discussion and sorry for the delay. This
would definitely be a nice feature to have but the people in the core
team, we won't have time to work on that ourselves. So it would be
amazing if you could help.
> 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.
We also documented a manual procedure here:
https://tails.boum.org/doc/first_steps/persistence/copy/
But yes, that's quite painful.
> 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
Here the user should be prompted about where to save the backup. Because
there might not be enough RAM on the computer to handle that, so they
might prefer to write that file directly in some other place, like an
external hard drive or USB stick.
> 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.
I'm also wondering whether it would be worth to ask the user which
folders of the persistence setup to backup. But maybe that's not needed
for a first prototype, as we might assume that the info in persistence
is kept to the minimum.
And also, do you think we should treat differently the data in
persistence that is not so personal, like APT lists and APT packages.
Those might compress pretty badly and occupy space for nothing in the
backups.
> 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.
Ack.
> Does anything look bad with this plan?
And what are your plans regarding the menus entries proposed to the
user? For the moment we have:
└── Applications
└── Tails
├── Configure persistent volume
└── Delete persistent volume
Maybe that could go all together in another entry, say "Backup and
restore persistent volume"?
--
sajolida
