Project

General

Profile

Feature #15653

Allow unlocking any persistent volume when multiple ones are available

Added by Gaff over 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Persistence
Target version:
Start date:
06/12/2018
Due date:
% Done:

100%

Feature Branch:
tails:feature/15653-15656-greeter-unlock,greeter:feature/15653-15656-greeter-unlock
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Greeter

Description

Change the greeter to support multiple encrypted persistence partitions. When the user enters a password, try that password against partition in turn until it finds a match.

Use cases:
  • Allow multiple users to share a tails device whilst still maintaining privacy.
  • Support plausible deniability / rubber hose protection - users can create several partitions and when pressed reveal the password to a unimportant partition

The code change for this is very simple. I've included a patch.

(Ideally the persistence-setup tool could be extended to support this, but that's much more work).

greeter.patch View (1.59 KB) Gaff, 06/12/2018 11:52 PM

greeter2.patch View (1.17 KB) Gaff, 06/14/2018 01:47 PM


Related issues

Related to Tails - Feature #5929: Consider creating a persistence by default for plausible deniability Confirmed 08/20/2016

Associated revisions

Revision 64727a7a (diff)
Added by intrigeri over 1 year ago

Import tails-greeter's feature/15653-15656-greeter-unlock branch at commit f434c12 (refs: #15653, #15656).

Revision 7ca8f128
Added by intrigeri over 1 year ago

Merge branch 'feature/15653-15656-greeter-unlock' into devel (Fix-committed: #15653, #15656)

History

#1 Updated by Gaff over 1 year ago

In-case anyone is wondering - I used the disk tool to add multiple luks partitions. It's important that they are all labelled 'TailsData'.

#2 Updated by Gaff over 1 year ago

Related-to / Partial solution of: https://labs.riseup.net/code/issues/5929

#3 Updated by mercedes508 over 1 year ago

  • Assignee set to Gaff

Gaff wrote:

Use cases:
  • Allow multiple users to share a tails device whilst still maintaining privacy.

It means for people we can't afford having their own Tails USB?

  • Support plausible deniability / rubber hose protection - users can create several partitions and when pressed reveal the password to a unimportant partition

This use case is already being worked on, but using another mean, persistent volume by default:

https://labs.riseup.net/code/issues/11681

#4 Updated by Gaff over 1 year ago

This use case is already being worked on, but using another mean, persistent volume by default

Sure - but my fix is compatible with the other fix. (Indeed they complement each other very well. One could suppose the default install comes with multiple persistent volumes - It would be impossible to know how many have been configured with passwords and how many were dummies).

Also my fix is cheap and has no downsides that I can see. And I've submitted a patch for it already (see above). Is there anything else I should do in order to get this considered for merge?

Thanks!

#5 Updated by intrigeri over 1 year ago

  • Related to Feature #5929: Consider creating a persistence by default for plausible deniability added

#6 Updated by Gaff over 1 year ago

  • QA Check set to Ready for QA

#7 Updated by intrigeri over 1 year ago

This use case is already being worked on, but using another mean, persistent volume by default:
https://labs.riseup.net/code/issues/11681

Err, it's not ever been worked on (yet) and that ticket is about deciding whether we want to implement that and how.

#8 Updated by intrigeri over 1 year ago

  • Status changed from New to In Progress

Allow multiple users to share a tails device whilst still maintaining privacy.

FWIW I don't remember this being ever requested in the past. It's hard to explain the amount of trust each of these users must put into all others: any of these users can patch the shared Tails system to log their passphrase and get access to their data. So "whilst still maintaining privacy" is pretty weak here.

  • Support plausible deniability / rubber hose protection - users can create several partitions and when pressed reveal the password to a unimportant partition

Given all persistent volumes are visible, I can't imagine an adversary, in such a threat model, being satisfied with being given access to only one of N>1 such volumes. So this use case is pretty weak IMO.

Regardless, I'll take a look at the patch and if it's really trivial, non-invasive and safe, why not.

#9 Updated by Gaff over 1 year ago

intrigeri wrote:

Allow multiple users to share a tails device whilst still maintaining privacy.

FWIW I don't remember this being ever requested in the past. It's hard to explain the amount of trust each of these users must put into all others: any of these users can patch the shared Tails system to log their passphrase and get access to their data. So "whilst still maintaining privacy" is pretty weak here.

I accept this use-case is pretty tenuous. It's mostly to frame justification for the other use case.

  • Support plausible deniability / rubber hose protection - users can create several partitions and when pressed reveal the password to a unimportant partition

Given all persistent volumes are visible, I can't imagine an adversary, in such a threat model, being satisfied with being given access to only one of N>1 such volumes. So this use case is pretty weak IMO.

True. It's strength is mostly against non-expert adversatories. This use case could be significantly strengthened if Tails created multiple partitions by default (something for another ticket).

Regardless, I'll take a look at the patch and if it's really trivial, non-invasive and safe, why not.

Cheers!

#10 Updated by intrigeri over 1 year ago

  • QA Check changed from Ready for QA to Dev Needed

I looked at the patch and indeed it's not scary:

  • The check_output_and_error change seems to be orthogonal to this ticket. If it's useful/necessary, please include it in a separate commit.
  • Please test how "Configure persistent volume" works on a device that has multiple GPT partition entries that all have the TailsData name. A quick look at the code suggests it might just work but I'd like a confirmation that one can still configure their persistent volume in such a case.
  • It would be nice to know how partitioning software behaves in front of a device that has multiple GPT partition entries that all have the TailsData name. Can you please test basic operations on such a drive with at least udisks2, parted and gfdisk and report back the results + how to reproduce them?

#11 Updated by Gaff over 1 year ago

intrigeri wrote:

  • The check_output_and_error change seems to be orthogonal to this ticket. If it's useful/necessary, please include it in a separate commit.

It's definitely a useful bugfix. Willdo.

  • It would be nice to know how partitioning software behaves in front of a device that has multiple GPT partition entries that all have the TailsData name. Can you please test basic operations on such a drive with at least udisks2, parted and gfdisk and report back the results + how to reproduce them?

I've been using parted, fdisk, and gnome-disks extensively to test this. Honestly these apps do little more than present the labels in the output / GUI. No issues whatsoever with this. [As an aside - one could argue that labelling your partitions TailsData is terrible for plausible deniability. Something for another ticket!]

  • Please test how "Configure persistent volume" works on a device that has multiple GPT partition entries that all have the TailsData name. A quick look at the code suggests it might just work but I'd like a confirmation that one can still configure their persistent volume in such a case.

Configuring an already-mounted device "just works". Obviously it's not possible to create multiple volumes this way - and I confess I didn't attempt to use the tool to delete a TailsData partition. Having said that - even if the tool fails it's not relevant for this ticket. There are dozens of ways to misconfigure your USB device such that the tool fails (trust me - I found a whole bunch of them while testing!). The tool doesn't pretend to work for every configuration, and I'm not pretending that multiple TailsData partitions are fully supported (yet). Even so this patch is good to go (IMHO).

#12 Updated by Gaff over 1 year ago

Attach a more limited patch.

#13 Updated by Gaff over 1 year ago

Moved the bugfix to #15656

#14 Updated by Gaff over 1 year ago

  • QA Check changed from Dev Needed to Ready for QA

#15 Updated by intrigeri over 1 year ago

I confess I didn't attempt to use the tool to delete a TailsData partition. Having said that - even the tool fails it's not relevant for this ticket.

Fair enough.

Please set the ticket as Ready for QA again whenever you feel it's ready for another review.

#16 Updated by intrigeri over 1 year ago

  • Assignee changed from Gaff to intrigeri
  • Target version set to Tails_3.9

#17 Updated by intrigeri over 1 year ago

  • Subject changed from Support multiple persistence partitions to Allow unlocking any persistent volume when multiple ones are available

(As per "I'm not pretending that multiple TailsData partitions are fully supported".)

#18 Updated by intrigeri over 1 year ago

  • Category set to Persistence
  • Estimated time deleted (1.00 h)
  • Affected tool set to Greeter

#19 Updated by intrigeri over 1 year ago

  • Feature Branch set to tails:feature/15653-15656-greeter-unlock,greeter:feature/15653-15656-greeter-unlock

Applied in a topic branch, let's see how it fares on Jenkins.

#20 Updated by intrigeri over 1 year ago

  • % Done changed from 0 to 20

#22 Updated by intrigeri over 1 year ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (intrigeri)
  • % Done changed from 20 to 100
  • QA Check changed from Ready for QA to Pass

Merged, thanks!

#23 Updated by intrigeri about 1 year ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF