On Fri, 11.11.16 11:12, Stephen Gallagher (sgallagh(a)redhat.com) wrote:
The hostname may always be set manually and the result will (for the
vast
majority of people) be unique within their environment. This means that if we
are concerned with hostname leakage being a privacy issue, we need to address
that at the leakage point, not at the hostname point.
Also, there are cases where hostname leakage may be used specifically *because*
it may be unique, such as one of several cues to the DHCP server. Unfortunately,
we cannot know in advance whether a DHCP server is going to be on a trusted or
untrusted network (we might be able to guess from the SSID of a WiFI connection,
but those are remarkably easy to fake).
In short, I really don't think that the hostname is the right place to solve
this problem. If transmission of individually-identifying information is a
concern, then we really have to solve it at the transmission points and not at
the source.
Yes, an argument could be made that a user who sets her own hostname is
"opting-in" to that uniqueness, but I think that's setting an unrealistic
expectation on all of our users that they fully understand the consequences of
that action.
I still believe we should stick to a generic hostname by default,
(though I'd rather use "localhost" than "localhost.localdomain"
in
order to drop the redhatism that "localdomain" is), and make the IPA
client-side enrollment code automatically update to a more "unique"
hostname if the hostname is found to be unset or be "localhost".
I am also pretty sure that DHCP clients should suppress sending local
hostname information if the local hostname is unset or "localhost".
* I like Zbigniew and Lennart's thoughts on how to generate the
"random" suffix.
the implementation I'd likely use is to take the first eight characters of an
md5 (or SHA) hash of /etc/machine-id and use those. That should make it both
repeatable and unique.
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..
Lennart
--
Lennart Poettering, Red Hat