Re: [OT] /etc/machine-id "must not be exposed in untrusted environments"
* Simon McVittie <smcv@debian.org> [190808 18:37]:
> On Thu, 08 Aug 2019 at 15:20:28 -0400, Marvin Renich wrote:
> > The man page for machine-id says:
> >
> > This ID uniquely identifies the host. It should be considered
> > "confidential", and must not be exposed in untrusted environments, in
> > particular on the network.
> >
> > Why is the file mode 0666?
>
> I very much hope it's 0644 (rw-r--r-- or 0444 (r--r--r--). Mine is 0444.
Sorry, that was an incorrect translation from reading r--r--r-- to
typing 0666 when I should have typed 0444. My next sentence expressed
my concern, which had nothing to do with the 0222 bits.
> > Does it need to be non-root readable?
>
> Yes. Some of the applications that want an opaque unique identifier for
> the machine, like dbus-launch(1) (which uses it to disambiguate between
> machines sharing an X11 display), are unprivileged. If /etc/machine-id
Okay. So, some unprivileged programs have a need to know (or at least
are currently implemented in a way that breaks if they cannot read it).
> > If
> > so, how can it be prevented from being exposed on the network if there
> > is any user access from the network? Is this really a security concern?
>
> If applications routinely broadcast the machine ID on local LANs or
> to an Internet server, then the operator of those LANs or servers
> can tell whether connections are coming from the same or different
> machines. Some people would consider this to be a privacy violation
> ("fingerprinting"). I suspect that the intention of that text is to
> encourage authors of networked software that uses the machine ID to
> think about this.
>
> Analogous: don't tell those same LANs or servers your gethostname(2),
> or your MAC address (without randomization), or your IPv6 address
> (without "privacy extensions"), if you don't want them to be able to
> tell which machine you are using.
I don't get this at all. Has there ever been a routine, best-practice
of having a machine that frequently changed its IP address to prevent
operators of other machines on the net from "fingerprinting"? (I'm not
talking about intentional use of an onion router.)
My point is that Debian as a distribution is used in a wide variety of
use cases, from locked-down server to single-user desktop to multi-user
application server (what used to be called time sharing).
Specifically in this last scenario, and to a lesser degree in others,
any world-readable file MUST be considered both LAN readable and
Internet readable. It is ludicrous to base any security on a
world-readable file (in the file permissions sense) being kept secret
from the real world.
My query was because the man page said "must not be exposed in untrusted
environments" and yet the file is world readable. These two are
absolutely and unequivocally incompatible.
There are both privacy and spoofing concerns any time a machine
transmits any information on the network. If that sentence in the man
page is aimed at application writers, then it should be reworded some.
One possibility is to remove that sentence and expand a little farther
down after the target audience is established:
This ID uniquely identifies the host. If a stable unique identifier
that is tied to the machine is needed for some application, using
the machine ID or any part of it directly could pose a privacy
concern. Instead the machine ID should be hashed with a....
(I didn't smooth out the sentence transitions, but it's a start.) This
avoids making a global, unqualified claim that cannot possibly be
maintained with the current implementation (i.e. mode 0444).
Alternatively, the file could be made mode 0400 and require all existing
applications that currently use it directly to be changed to use an API
such as sd_id128_get_machine_app_specific(3). I suspect that this is
neither necessary nor practical, based on my new understanding from your
explanation.
BTW, thanks for your explanation; it did clear up the intent. I now
believe this is just over-zealous documentation, which is much easier to
correct!
...Marvin
Reply to: