[RFE] Public API for requesting unique values derived from machine-id

[sgallagher]

Submission type

• Bug report
• Request for enhancement (RFE)

During recent discussions on the Fedora development mailing list, we have been discussing ways that we might generate a default hostname based off of the machine-id. Lennart suggested the following:

Please do not use MD5 anymore. And please calculate your ID as

       SHA(x || k)

x refers to the machine id, "||" refers to concatenation and "k"
refers to some app-specific key (which is OK to be publically
known). It's important to concatenate the app-specific key, so that it
is not possible to map the machine IDs used by one app to the machine
IDs used by another..

It was also discussed later in the same thread that:

Which lies in the problem. If people are going to derive hashes from
it they will do so any way the want and most likely it will be leaked
out by someone doing a sum  or just copying it etc. If there is
something 'unique' on a system, it will leak out eventually. All you
can do is try to design to drip out slowly or pour out all at once.

-- Stephen John Smoogen

My response here is that what we should do is have systemd provide an official API for generating unique values derived (repeatably) from the machine-id that are irreversible. By having it come from systemd, we can strongly encourage people to use this version as the safe approach and thereby discourage roll-your-own implementations or just direct use of the machine-id.

I suggest something similar to:

const char *
generate-machine-id(uint64_t app-specific-key,
                    char *acceptable_chars,
                    size_t num_characters)

(C example given, but probably we'd actually want this in D-BUS to be
language-agnostic.)

[grawity]

I'm not sure if SHA(x || k) is the best choice; I think HMAC is the usual recommendation for keyed hashes?

Related: I wonder if the existing o.f.DBus.Peer.GetMachineID, as implemented in sd-bus, should return a keyed ID instead of the real one. (Keyed with the service's DBus name, maybe?)

$ gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.DBus.Peer.GetMachineId
('c36...',)

[sgallagher]

Sorry, I meant to write into the description above that others had recommended HMAC over the specific approach that @poettering had suggested, but I missed it. Thanks for commenting.

I wouldn't recommend attempting to reuse that existing call for two reasons:

• An update to systemd might change the value that applications are seeing, which could cause failures in unforseen ways. This is basically an API compatibility breakage.
• Not all applications that might want this information will necessarily have well-known D-BUS names and one of the requirements was that this should be repeatable. So it would be best if the application-ID was explicitly provided by the querying application.

[poettering]

Makes sense to add, indeed.

[poettering]

Suggested implementation for this waiting in #4686. Please have a look.

[smcv]

For the record:

I wonder if the existing o.f.DBus.Peer.GetMachineID, as implemented in sd-bus, should return a keyed ID instead of the real one. (Keyed with the service's DBus name, maybe?)

No, it must return the real machine ID, the same as the dbus-daemon's o.fd.DBus.GetMachineID, which in turn is the same as /etc/machine-id on correctly-set-up systemd systems.

Rationale: the original purpose of o.fd.DBus.Peer.GetMachineID() is that you can compare it with o.fd.DBus.GetMachineID(), or with the result of reading the machine ID yourself, to determine whether the peer is running on the same machine as the dbus-daemon or on the same machine that you are running on. If it isn't, then you can't usefully share file descriptors, local filesystem paths, process IDs, etc. with it. Whenever you see "machine ID" in D-Bus, think "hostname, but without collisions".

This was useful when D-Bus was first designed, with a TCP-shared dbus-daemon accompanying NIS users, an NFS-shared home directory and X11-over-TCP being one of the use-cases. None of the current maintainers recommend or support that situation, but it's still part of the design.