Feature #15938
Persistent volume on sshfs
0%
Description
As of now, Tails can mount a directory from a hidden (onion) SSH server out of the box. This just works as the non-root ‘amnesia’ user. Thanks very much for that guys.
So it would be natural to consider using sshfs as backing store for the persistent volume file.
Currently the persistent volume is just a LUKS partition, which can be a problem in some scenarios. Suppose a Tails user visits an oppressive state and their place of stay gets raided by the secret police. Then the user will have to answer a lot of hard questions about the LUKS partition. In the worst case, rubber-hose cryptanalisys will be used and the Tail user will have a really hard time not disclosing the volume password. If the persistent volume gets hosted in a free country instead, there will be no evidence of it available to the adversary (at least from the Tails USB stick) and the Tails user will have a better chance to maintain they have no hidden data of any sort.
It is already possible to mount an sshfs-based LUKS volume manually after just one system change: uncomment user_allow_other in /etc/fuse.conf so the root user can access the LUKS volume file over sshfs for device-mapper purposes. The rest is straightforward:
$ sshfs user@xyz.onion:disks /mnt/disks
$ sudo cryptsetup luksOpen /mnt/disks/luksdisk sshdisk
$ sudo mount /dev/mapper/sshdisk /mnt/persistent
So it looks like the tricky part is going to be the integration of the procedure into Tails.
Thank you guys for considering this idea.
Subtasks
Related issues
|
Related to Tails - |
Rejected | 2016-08-20 |
History
#1 Updated by goupille 2018-10-16 10:27:26
- related to
Feature #11681: Decide if/how we want plausible deniability for the persistent volume added
#2 Updated by goupille 2018-10-16 10:28:32
- Assignee set to intrigeri
#3 Updated by intrigeri 2018-10-16 13:07:49
- Status changed from New to Rejected
- Assignee deleted (
intrigeri)
I acknowledge the value of the goals being pursued here.
My experience with sshfs is that its semantics are too different from a “normal” FS to work reliably as a backing store for arbitrary data used read-write by arbitrary software, which is what at least some of our persistence features are about. It would probably work fine for user data such as ~/Persistent but I would not dare persisting e.g. the Thunderbird profile on sshfs. So I think that implementing the “persistent volume on sshfs” proposal would require not only a lot of development work but also a lot of design work, to make it clear what the pros and cons are, to avoid letting the user pick options that won’t work, to design how it would work in the Greeter and in the persistence setup assistant. Given I bet only rather technical users will be able to get a SSH account on a trusted machine and use this feature, I think the cost (for us) / benefit (for our less technical primary target users) is not worth it.
In passing, some of our persistence features are about data owned by different users than amnesia, which I think would require running sshfs as root and using its idmap option, which makes the initial setup (that’s not done as root) harder to implement.
Feel free to reopen if I’ve closed this based on a mistaken analysis :)