Tails

#2 Updated by intrigeri 2016-11-04 08:26:53

• QA Check set to Info Needed

#4 Updated by intrigeri 2016-12-06 20:10:28

• QA Check deleted (Info Needed)
• Type of work changed from Debian to Discuss

Personally, I’d rather not open the “let’s try to make the content of the RAM / read-write aufs branch amnesic” can of worms. Seems too much like a lost battle, lots of wasted time in perspective, for very little benefit. One should not expect that the activity from current Tails session can be erased without shutting down the system and letting the memory erasure process do its job.

#5 Updated by intrigeri 2016-12-06 20:11:24

• Feature Branch set to https://gitlab.com/ephiphone/tails/tree/feature/11882-disable-gnome-history

#9 Updated by mercedes508 2017-01-08 12:08:15

• Assignee set to elouann

#10 Updated by intrigeri 2017-01-08 12:26:51

• Subject changed from disable recent usage and history in privacy settings by default to Consider disabling recent usage and history in privacy settings by default
• Status changed from New to Confirmed
• Assignee deleted (elouann)

#11 Updated by segfault 2017-03-08 14:11:08

• Assignee set to intrigeri

We talked about this during the contributors meeting. We agreed that we are not convinced the proposed patch would be a security improvement. Intrigeri will write another comment here, explaining our thoughts and asking for clarification.

#15 Updated by intrigeri 2017-04-02 09:17:26

• Subject changed from Consider disabling recent usage and history in privacy settings by default to Consider disabling recent usage and history in privacy settings

#16 Updated by intrigeri 2017-04-02 09:54:01

• Starter changed from Yes to No

So, I’ll reason about “my Tails session is compromised and I want to hide the list of files I have worked on”. Let’s study the various sub-cases, depending on where these files are stored:

• on an external device:
  • local attacker
    • encrypted storage device: as long as the attacker doesn’t get the passphrase/key, then disabling usage history hides which files were open
    • cleartext storage device: the atime/mtime of the files will reveal the same info as the usage history would
  • remote attacker
    • external device still plugged: the atime/mtime of the files will reveal the same info as the usage history would
    • external device not plugged anymore: disabling usage/history helps
• on the Tails root filesystem (e.g. in non-persistent parts of $HOME):
  • files opened only for reading: we don’t store atime in aufs, so disabling usage history helps; but any file opened only for reading has to be on the ISO, so arguably the advantages of hiding that they were accessed are very minor
  • files modified: the aufs RW branch will reveal the same info as the usage history would
• in Persistence:
  • files opened only for reading: we don’t store atime on the persistent volume, so disabling usage history helps
  • files modified: the mtime fo files will reveal the same info as the usage history would

Summing up, it seems to me that disabling usage history can only help for:

• files on an external device that has already been unplugged (vs. remote adversary) and is encrypted (vs. local adversary)
• files on the Tails medium (SquashFS or persistent volume) that have only been opened for reading, and not modified

That’s not much.

Also:

• The proposed change brings a non-negligible usability regression.
• In most cases discussed above, the content of accessed files is available to the attacker. So the only advantage of disabling GNOME usage/history is hiding that these files were accessed.
• Not all software honors the GNOME usage/history settings. E.g. I suspect that LibreOffice and other non-GNOME applications don’t. Of course, not being able to protect against this attack scenario perfectly is not a good reason to keep things as-is, but still: users won’t be able to rely on the fact we disable usage/history. IMO a security measure that one can’t rely upon is not very useful to real-world users.
• Until we do Feature #12089 and Feature #12090, regardless of the GNOME usage/history settings, information about past activity will remain in RAM, available to an attacker who gets root or physical access: the GNOME usage/history only controls whether this info is saved on the filesystem in an easy to read format. And even once we have Feature #12089 and Feature #12090, disk caches also contain at least part of the very info that we’re trying to hide here.

So, at this point my conclusion is that the security benefits brought by the proposed change (in some limited cases, and against a relatively weak adversary who can’t extract info from RAM) don’t outweigh the usability hit.

#17 Updated by intrigeri 2017-04-02 09:56:24

• Status changed from Confirmed to In Progress
• Assignee changed from intrigeri to epiphone
• % Done changed from 0 to 10

epiphone, can you please have a look at my reasoning above (spot the mistakes :), and share the thoughts you now have on this topic? Thanks in advance!

#18 Updated by Anonymous 2018-01-19 13:34:42

• Status changed from In Progress to Rejected

No news since 10 months. Rejecting.