Tails

#1 Updated by Gaff 2018-06-18 11:18:43

• related to Feature #11681: Decide if/how we want plausible deniability for the persistent volume added

#2 Updated by Gaff 2018-06-18 11:21:25

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

#3 Updated by Gaff 2018-06-18 11:22:16

• related to Feature #6621: Allow creating persistent volume onto a separate device added

#5 Updated by Gaff 2018-06-18 12:12:33

• QA Check set to Info Needed

I’ve had a look and it’s pretty simple to fix this. Changing `/usr/local/sbin/live-persist’ so that it lists any luks partition is a few lines of code. I’m happy to make the change.

The only slight risk is if all of the following hold:

• Users have specified at boot time that tails can mount other devices (via `live-media=`), or Feature #6621 is implemented, or Users have manually setup their device with multiple Luks partitions
• and the other luks device should not be mounted by tails (Because it shouldn’t be written to perhaps?)
• and the password supplied for the luks device matches

In this situation Tails will mount the device regardless - and potentially make changes since activating a partition is a write-operation :o) !!
From my reading of the persistnce-setup perl code the filesystem label inside the luks container is always set to ‘TailsData’, so we could add a check in the greeter after it runs luksOpen to check and prevent this situation. (which I’m happy to code too).

Does anyone have any thoughts?

#6 Updated by goupille 2018-06-20 11:59:00

• Status changed from New to Duplicate
• Assignee deleted (Gaff)
• QA Check deleted (Info Needed)

I think that’s duplicating Feature #5929

#7 Updated by goupille 2018-06-20 12:35:54

• Status changed from Duplicate to New
• Assignee set to intrigeri
• Parent task set to Feature #5929

#8 Updated by intrigeri 2018-07-03 10:25:43

• Assignee changed from intrigeri to Gaff
• Parent task deleted (Feature #5929)
• QA Check set to Info Needed

Before I spend time thinking of whatever complications this proposal might bring, I’d like to understand the expected benefit of doing this work. As long as the Tails device obviously contains a LUKS volume, I don’t get it: under what threat model is the label of the partition that hosts a LUKS volume relevant to plausible deniability?

#9 Updated by Gaff 2018-07-03 10:37:08

• Assignee changed from Gaff to intrigeri

intrigeri wrote:
> Under what threat model is the label of the partition that hosts a LUKS volume relevant to plausible deniability?

The most likely scenario is when Feature #6621 is implemented (Store the persistent partition on a seperate device). In this scenario one might reasonably want to deny that you own a persistent partition at all.

The benefit might be small / specialised, but (apart from the very minor edge case I mention) there’s no downside.The cost of this change is pretty cheap.

#10 Updated by intrigeri 2018-07-03 11:39:52

• Assignee changed from intrigeri to Gaff

> intrigeri wrote:
>> Under what threat model is the label of the partition that hosts a LUKS volume relevant to plausible deniability?

> The most likely scenario is when Feature #6621 is implemented (Store the persistent partition on a seperate device).

That’s a 4 years old, low priority ticket. I’d rather make any decision based on the assumption that it’s going to be implemented any time soon. I’m not even sure it’s a good idea to implement it.

> In this scenario one might reasonably want to deny that you own a persistent partition at all.

I still don’t get it: even if the LUKS volume on that other stick is not obviously a Tails persistent volume, under what threat models does it make a difference, considering it’s obviously encrypted data?

> The cost of this change, but for the edge case I list, is very cheap.

I think it’s more complicated than that but I won’t spend time on this until the expected benefits are clarified.

#12 Updated by Gaff 2018-07-03 12:28:10

• Assignee changed from Gaff to intrigeri

#13 Updated by intrigeri 2018-07-28 05:21:55

• Status changed from New to Rejected

>> I still don’t get it: even if the LUKS volume on that other stick is not obviously a Tails persistent volume, under what threat models does it make a difference, considering it’s obviously encrypted data?

> Imagine you’re the adversary, you discover some USB devices on a suspect. […]

I see. IMO the difference it makes is quite small, but more importantly (wrt. how we allocate Tails resources): it will benefit very, very few people.

> Can I invert the question? Given that labelling the partition ‘TailsData’ can only ever make things worse. What technical upside is there for doing this? I see none.

The requirement we currently have:

• makes it very easy to detect whether a persistent volume exists, with very little code, regardless of the programming language; while the algorithm you’re proposing is more complex and probably harder to implement in N>1 programming languages without code duplication
• allows us to special-case the persistent volume e.g. /etc/udev/rules.d/99-hide-TailsData.rules

More generally, every constant you turn into a variable has the potential to make maintenance and new development harder or more expensive, which is why we need strong reasons to make such changes. In the case at hand, with my Foundations Team hat on, I don’t think the advantages brought by this proposal are worth making our future maintenance/development work harder, so I’m hereby rejecting this ticket. If you want to appeal this decision to the broader Tails community, feel free to reopen, set “Type of work = Discuss” and follow https://tails.boum.org/contribute/meetings/#preparing-a-discussion so this is discussed at a monthly meeting.