Re: [Tails-ux] Clone Persistence option in Tails Installer (…

intrigeri:
> sajolida:
>> I'd like, most of all, opinions from coders on the cost of such a
>> solution
>
> I'll start by asking some clarifications and replying on some
> minor points.

Thanks for the prompt feedback!

>> - To prevent people confusing their current Tails with their backup
>> Tails, the backup Tails could be aware that it is a backup Tails and
>> display some warning when first started. Otherwise, changes made on
>> the backup Tails would be overwritten when the backup is updated.
>
> If we can use a bit in the GPT partition flag space (see the ticket
> about storing the Tails version number in there for technical
> details), then this should be reasonably cheap.

#8862 (Display version number of destination device in Tails Installer)
is unclear about why a GPT flag is needed. I understand that, in the
context of #8862, it would allow knowing the version number without
mounting the system partition of the destination Tails.

I think that the context of backups is different and doesn't even
require a GPT flag. I first thought about storing this information in
the system partition so it could be displayed (and localized) as soon as
Tails Greeter opens. But I understand that the system partition is
read-only so maybe that's not an option: the user wouldn't be able to
confirm that they want to use their backup Tails and erase this flag
from Tails Greeter.

But actually, in the context of backups, this information doesn't matter
until the Persistence is unlocked, so this information can probably be
stored in the Persistence of the backup Tails and still displayed in
Tails Greeter as soon as the Persistence gets unlocked and before the
GNOME session.

>> Before the backup Persistence is being created, the user is prompted for
>> a passphrase.
>
> What is this passphrase used for?

To create the Persistence on the backup Tails. I assumed that we would
work at the file system level.

I did a bit of research on cryptsetup to see if we could reuse the
encryption key and the passphrase of the current LUKS volume to create
the LUKS volume of the backup Tails in a way that would be transparent
to the user but I don't think that's possible without writing kernel code :)

>> Update
>> ------
>
>> Before the backup Persistence is being updated, the user is prompted for
>> a passphrase.
>
> Here as well, what for?

To unlock the Persistence of the backup Tails.

>> ### Open questions
>
>> - Is it fine to copy the content of the current Persistence while it is
>> being used?
>
> Doing so creates inconsistent backups: among a set of files that are
> supposed to go together (be it config, program data, user data), some
> of them are backup'ed at version N while some others at version N+1.
>
> Inconsistent backups ⇒ inconsistent data sets. That can break
> software's ability to use the data at various degrees. I can't tell
> off-hand how bad this can be but it has the potential to make software
> with large and complex data store, such as Thunderbird,
> really unhappy.

Understood. Then we should prevent users from updating their backups
while the problematic applications are open.

To polish the experience a bit, it might be worth investigating which
applications are really problematic in practice, and not only in theory.

>> - How can we handle to preserve permissions and ownership when doing
>> the backup without having users to set up an administration password
>> to create or update their backup?
>
> If we work at the filesystem level, i.e. unlocked persistent volume:
> I think we'll need a privileged backend. Feasible but much more work
> than "a few dozens of lines of code in Tails Installer".
>
> If we work at the block device level, i.e. locked persistent volume:
> we need either a privileged backend (as above) or to give the amnesia
> user appropriate PolicyKit permissions (which might be too dangerous
> to be an option; note that we already give write access to raw block
> devices since 9c82fe6a35aa0a3a1fc605d2d5e33b78218f59fc).

I thought about working at the file system level, which explains why I
would ask the user for a passphrase when creating and updating the backups.

I was afraid that working at the block device level wouldn't satisfy the
"Fast and simple" and thus the "Fresh" requirements.

I assumed that working on the block device level would mean copying the
whole Persistence partition block by block every time. Doing a dd of
Tails (1.2 GB) to a USB stick takes around 5 minutes, so doing full copy
of a 5.5 Persistence would take around 30 minutes. Not fast. Especially
if you can't use Thunderbird while your backups are updating.

But maybe there are more efficient ways of operating at the block level
that I ignore!

>> - How much can we organize this code to be easier to possibly extend to
>> scenarios S2, S3, and S4 in the future?
>
> I doubt it's a matter of how we organize this code. But some UX +
> implementation options will make some of these other scenarios easier
> to support than others (see below).
>
>> Future
>> ======
>
>> Once we have a solid solution for S1, we might able to reuse some of
>> it's UX and code to solve scenarios S2, S3, and S4.
>
> S2 and S4 would probably be easier if we work at the filesystem level.
>
> S3 might be facilitated by working at the block device level (as
> opposed to filesystem level).

How so?

S3 is: I want to cross a border with no data on me.

The scenario I imagined for S3 would be:

1. I cross the border with no Tails device at all with me.
2. I install Tails on the other side of the border.
3. I get my Tails to fetch all my files online.

I thought that this might work as well on the file system level.
At least it's how I do it when I cross borders with no data on me :)

--
sajolida