Use the new Tails Persistent Storage copy option where applicable #492
Conversation
…ring onboarding By using ssh-add before ssh-copy-id on the new Admin Workstation 2 (AW2), all steps once Tails is installed on AW2 can take place on AW2 with the existing Admin Workstation 1 (AW1) unlocked, rather than running some steps on AW2 with AW1 unlocked and some steps on AW1 with AW2 unlocked. This adds a couple of shell commands (a possible source of error) but removes 5 steps and some shuffling of thumb drives (a different possible source of error). Assumptions: * If we trust AW2 to have AW1 unlocked, then we trust AW2 to load AW1's SSH private key into memory and use it to connect to the Application and Monitor Servers, in order to upload AW2's own SSH public key. * In other words, each Admin Workstation has its own keypair to allow revocation of individual keys, not because a given Admin Workstation or its owner cannot be trusted to have access to another Admin Workstation's full keypair (in a procedure in which, in fact, they *do* have such access).
…e copying options.
…rage copy options.
nathandyer
force-pushed
the
tails-copy-pv
branch
from
5dae3b7 to
f7b6b1b
Compare
|
@nathandyer, I'm sorry this has sat neglected. Before you address @zenmonkeykstop's latest feedback, it looks like there are now conflicts (that may also conflict with that feedback). Let me know if I can help revise or test this once those are resolved. |
nathandyer
force-pushed
the
tails-copy-pv
branch
from
827e3eb to
18edb46
Compare
|
Thanks @zenmonkeykstop for the latest review, and @cfm for flagging the merge conflict. I believe I have fixed the conflict, and addressed the requested changes. One thing to note, in the interim since this was filed, we've already updated the SVS section to point users to the upstream Tails' guide (which I think is also new since I originally filed this PR). I've elected to keep that revision rather than the explicit guide I had started here for that section; that said, because the cloning of Admin Workstations is a bit more involved, I think it makes sense to explicitly guide users through each of the steps. Please let me know what you all think of its current form. |
There was a problem hiding this comment.
Thanks for revising this, @nathandyer. I haven't stepped through it manually again, but in reading through it I have one order-of-operations question (inline). If my question makes sense, it should be an easy fix; if not, let's chat tomorrow and you can let me know what I'm missing!
| on your servers: | ||
|
|
||
| * ``ssh-add`` | ||
| * ``ssh-add /media/amnesia/TailsData/openssh-client/id_rsa`` |
There was a problem hiding this comment.
If we've booted AW2 in new step (10), then /media/amnesia/TailsData is AW1's persistent storage. Don't we still need old step (12) to mount AW1 and old step (17) to unmount it?
There was a problem hiding this comment.
@cfm I don't believe so; /media/amnesia/tailsData should be AW2's persistent storage, not AW1s. Unlike the original instructions, we're never actually copying directly from AW1 to AW2 (I mean that in the spiritual sense, rather than literal - the contents of that persistent volume are being copied, it's just a more transparent operation during the drive creation process). With the Tails Cloner, AW1's persistent storage gets duplicated as AW2's during the cloning (because of the option checked in new step 6). So when you shut down AW1, boot into AW2, and then unlock the storage, at that point AW1 is completely out of the picture.
There was a problem hiding this comment.
Noting for the sake of posterity here within the ticket: I just had a great conversation with @cfm, who explained that the issue here is that step 12 (as it stands) overwrites the existing SSH key, so that step 14 is no longer possible due to the original SSH key (needed for adding the new SSH key to the servers) is not available.
The fix to this is to add a few additional steps to insert AW1, unlock persistent storage, perform step 14, then remove AW1 again.
Commit incoming.
There was a problem hiding this comment.
Thanks for conferring about this, @nathandyer. Last volley, I promise: I think we should keep the step-by-step instructions for handling AW1 in step (14), especially since with the Cloner the user now won't have had to do other un/lock operations with the file manager.
nathandyer
force-pushed
the
tails-copy-pv
branch
from
1eb8559 to
579b5d5
Compare
nathandyer
force-pushed
the
tails-copy-pv
branch
from
579b5d5 to
86f5d8e
Compare
There was a problem hiding this comment.
I stepped through this earlier today for the discussion that's led to 86f5d8e, and with that change this procedure works as intended. Thanks a bunch, @nathandyer, not least for your patience in shepherding this!
Status
Ready for review
Description of Changes
This modifies the workflow in a couple key areas to use the new option in the Tails Installer that can copy an existing drive's Persistent Storage during a cloning operation.
It's worth noting that I elected not to use this tool for the backup procedures, instead preferring the current rsync based approach. This is because the current process allows for multiple workstation backups onto a single drive, which the Tails Installer tool does not allow. For that same reason, I have left the previous steps in place regarding the use of
securedrop-admin backupandrestore.The second commit here changes the workflow for making a remote Secure Viewing Station. It does eliminate the use the "primary" USB drive, opting instead to clone the current SVS entirely (from an airgapped system). With this being a change in procedure with security implications, it may not be one we feel comfortable making; if not, I'm happy to remove that commit.
I will also note that I captured screenshots of the new Tails Installer, but did not feel it added to the documentation, so I elected to leave them out. If we believe it's worth including them, I can do so relatively easily.
Testing
Checklist (Optional)
make docs-lint) passed locallymake docs-linkcheck) passedmake docs) docs at http://localhost:8000