Feature #7100

Decide what to do with machine-id

Added by intrigeri 2014-04-16 16:50:49 . Updated 2019-02-24 11:16:13 .

Status:
Confirmed
Priority:
Normal
Assignee:
bertagaz
Category:
Target version:
Start date:
2014-04-16
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

Modern GNU/Linux tools (D-Bus, systemd) relies more and more on /etc/machine-id and/or /var/lib/dbus/machine-id (depending on the OS, versions, etc.). In most situations we care about, if not all, this ID should not be leaked to the network. If it is, then:

  • if we set the same machine-id everywhere, then users are all in the same anonymity set; but this also leaks that they’re using Tails
  • if we set unique machine-id on boot, then we don’t leak that users are using Tails, and applications that rely on machine-id working on the LAN work; OTOH, if machine-id leaks on the Internet, then the fact that users are not in the same anonymity set can be a problem

We should first evaluate if/how machine-id can be leaked, and then think about this all, and decide something.

team: bertagaz


Subtasks


Related issues

Related to Tails - Feature #5821: Switch to systemd as pid 1 Resolved 2014-05-09 2015-06-01
Related to Tails - Feature #5630: Reproducible builds Resolved 2015-09-23

History

#1 Updated by BitingBird 2015-01-03 05:06:43

#2 Updated by intrigeri 2015-05-17 10:08:16

Note that live-build 5.x deletes /var/lib/dbus/machine-id and empties /etc/machine-id.

#3 Updated by intrigeri 2015-05-17 10:11:40

  • Assignee set to intrigeri

Adding to my radar.

#4 Updated by intrigeri 2015-06-04 15:33:21

Note that if we decide to make machine-id a per-Tails-boot identifier (as opposed to the current per-Tails-version identifier), we’ll need to check our AppArmor profiles and see if they allow apps to access those file, why, how dangerous it is, and whether we want/need to keep allowing it.

#5 Updated by intrigeri 2015-07-13 03:54:23

  • Assignee deleted (intrigeri)
  • Target version set to Hardening_M1

#7 Updated by upqoer 2015-07-20 03:53:42

This can be an issue.

> if we set the same machine-id everywhere, then users are all in the same anonymity set; but this also leaks that they’re using Tails

Go for this one.
Because:

If you would go for random-id on each boot, then this issues will appear:

  • Person is trapped whole time while running Tails instance with the same machine-id. That means if it will get leaked by the browser or anyhow, and user will want New Identity, he will still be trackable by this attribute.

Setting hardcoded machine-id, Tails-specific is way better idea for anonymity.

Also note this:

Tor Browser in Tails can read this file! (/etc/machine-id). See Tails current AppArmor profile allowing Tor Browser read from machine-id:

/etc/machine-id r,

https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/usr/share/tails/torbrowser-AppArmor-profile.patch

Deny it. Why would Tor Browser need the access to this file? And what about other applications like Pidgin, Evince, Electrum and all the others? They will not work without access to it? Has anybody tested this out?

#8 Updated by sajolida 2015-08-14 11:49:52

  • Assignee set to bertagaz

#9 Updated by sajolida 2015-09-10 12:03:23

  • Target version changed from Hardening_M1 to 2016

#10 Updated by Dr_Whax 2016-08-20 13:34:56

  • Description updated
  • Target version changed from 2016 to 2017

#11 Updated by intrigeri 2016-11-20 14:06:47

#12 Updated by intrigeri 2016-12-05 09:28:22

Also see this interesting thread about this topic on the AppArmor mailing list. Simon McVittie is the upstream D-Bus maintainer, and is familiar both with AppArmor and privacy concerns.

And of course, commit:0d5d4d4.

#13 Updated by Anonymous 2018-01-15 14:08:34

  • Target version changed from 2017 to 2018

2017 is over.

#14 Updated by Anonymous 2018-08-18 13:58:31

Any news on this one?

#15 Updated by intrigeri 2019-02-24 11:16:13

  • Target version deleted (2018)

2018 is over and this did not make it on our roadmap for next year (incomplete team).