RFC (round 2): Change the default hostname for Fedora 26+
The original thread is getting rather long and I'd like to attempt to summarize the discussion thus far and see if we can find a way forward from there. First, some clarifications for preconditions that some people were unaware of (either on this thread or the ones that popped up on other lists/forums): 1) Fedora has always allowed the hostname to be changed in Anaconda. It's perhaps not in the most obvious of places (the networking spoke), but it's there. It can also be set via kickstart, of course. 2) The default today is to use a name provided by the DHCP server if it offers a name for that device, otherwise it will fall back to localhost.localdomain (the common case for most personal networks). 3) My original proposal was: change the fallback name to Fedora- by default, while of course retaining the ability to set it manually. 4) The specific issue relating to FreeIPA and Active Directory is one of uniqueness: you can only have one machine named "localhost" enrolled in a domain. A user who is unaware of the hostname at all will not know to change it ahead of time. The thread on Fedora Devel revealed some other issues which need to be considered carefully. One of these is that of privacy: for example, the DHCP client will send the machine's hostname as one of the cues to the DHCP server for acquiring a lease. While this is fine on private networks, there's a valid concern that this might be undesirable on a public hotspot. (This is only one such example; there may be other places where the system transmits the hostname). With machines commonly defaulting to localhost.localdomain, getting this information tells the recipient little more than that a Fedora-derived machine is connecting (since it's the only known ecosystem that uses this specific default). However, the more unique we make the name, the easier it becomes to isolate it to a single system (such as for tracking purposes). It is an open question whether this is an actual problem to worry about or whether it's a drop in the proverbial bucket. It's also worth noting of course that any manually-chosen hostname will have this same problem, which begs the question of whether it's worthwhile to do anything about it at all. (Or perhaps that the focus should be on not leaking the hostname itself elsewhere, regardless of how it was created). I hope this frames the discussion better. My thoughts from here: 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. Further, from a purely technical perspective, I think I've been swayed by arguments around the generation of the hostname: * I'm fine with the lowercase "fedora-" prefix. It makes sense since hostnames are generally normalized to lower-case in common usage. * 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. For Anaconda folks: would it be possible to have the currently-selected hostname be visible next to the "Networking" spoke on the main hub page? You show the selected environment group beside the "Software Selection" spoke and the connected network device, so it might be useful to let people know what the hostname is as well. (This would also be handy if it turns out that DHCP is trying to assign a hostname; the user may not want or expect that) signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
Once upon a time, Stephen Gallagher said: > The thread on Fedora Devel revealed some other issues which need to be > considered carefully. One of these is that of privacy: for example, the DHCP > client will send the machine's hostname as one of the cues to the DHCP server > for acquiring a lease. While this is fine on private networks, there's a valid > concern that this might be undesirable on a public hotspot. I manage several DHCP servers for service providers and public venues. While it is true that the client-provided hostname is logged, I would say it is of little value to someone trying to use that information (the number of "Jeff's iPhone" and such is very high). Also, if someone was trying to identify you from DHCP, they have your MAC address to tie everything together with (so they know if you have a Dell notebook or a Samsung tablet for example), and they can also narrow down OS and such by requested options or their absence (and that can start narrowing it down to releases as well). I think concerns about "leaking" a generated hostname are pretty minimal. If someone is concerned about that, there are a number of other changes they'll probably be making, and they can set a non-default hostname in that process. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Fri, Nov 11, 2016 at 10:47:47AM -0600, Chris Adams wrote: > I think concerns about "leaking" a generated hostname are pretty > minimal. If someone is concerned about that, there are a number of > other changes they'll probably be making, and they can set a non-default > hostname in that process. Continuing what Stephen Smoogen just said in another thread about "stone soup", what I'd *really* like to see is people who are interested in improving Fedora's network privacy footprint make a Remix — or even a Spin with greater-than-usual modifications — with that as the goal. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Fri, 11.11.16 11:12, Stephen Gallagher (sgall...@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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Fri, Nov 11, 2016 at 9:08 AM, Lennart Poettering wrote: > On Fri, 11.11.16 11:12, Stephen Gallagher (sgall...@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.. > /me dons crypto hat. SHA(x || k) has three problems, one of which is bad enough to be an absolute showstopper. 1. Specify *which* SHA. SHA-1 should not be used for new applications. 2. Concatenation without some additional property preventing collisions of the hashed data is problematic. In particular, if you shorten x by a byte and prepend the same byte to k, you get the same output. This is probably irrelevant for this particular use case, but it's still a sign that the construction is bad. 3. The SHA hashes, like all Merkle-Damgård hashes, is subject to length-extension attacks. In particular, if x is a multiple (or slightly above a multiple) of the block length, then anyone who learns SHA(x) can efficiently derive SHA(x || k). This basically removes all security from this scheme. HMAC(k, x) would be much better. But I think this protocol is generally more fragile then needed. How about generating a per-app-installation random value and HMAC-ing *that* with the machine id? --Andy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Fri, Nov 11, 2016 at 8:47 AM, Chris Adams wrote: > Once upon a time, Stephen Gallagher said: > > The thread on Fedora Devel revealed some other issues which need to be > > considered carefully. One of these is that of privacy: for example, the > DHCP > > client will send the machine's hostname as one of the cues to the DHCP > server > > for acquiring a lease. While this is fine on private networks, there's a > valid > > concern that this might be undesirable on a public hotspot. > > I manage several DHCP servers for service providers and public venues. > While it is true that the client-provided hostname is logged, I would > say it is of little value to someone trying to use that information (the > number of "Jeff's iPhone" and such is very high). > > Also, if someone was trying to identify you from DHCP, they have your > MAC address to tie everything together with (so they know if you have a > Dell notebook or a Samsung tablet for example), and they can also narrow > down OS and such by requested options or their absence (and that can > start narrowing it down to releases as well). > > I think concerns about "leaking" a generated hostname are pretty > minimal. If someone is concerned about that, there are a number of > other changes they'll probably be making, and they can set a non-default > hostname in that process. > I thoroughly disagree. NetworkManager already has the ability to randomize MAC addresses to keep them from leaking. DHCP options and such will, at most, identify your distro and maybe some installed packages. The fact that some NetworkManager settings will leak the MAC address is *not* an excuse to leak a hostname. Privacy and security issues are never solved by saying "well, there's already a problem, so let's add a new problem". Right now, if you leave your hostname at the "localhost" default, randomize your MAC, and route everything over a VPN, you're actually doing quite well. Let's not make it worse, please. --Andy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 11/11/2016 12:17 PM, Andrew Lutomirski wrote: > /me dons crypto hat. > > SHA(x || k) has three problems, one of which is bad enough to be an absolute > showstopper. > > 1. Specify *which* SHA. SHA-1 should not be used for new applications. > > 2. Concatenation without some additional property preventing collisions of the > hashed data is problematic. In particular, if you shorten x by a byte and > prepend the same byte to k, you get the same output. This is probably > irrelevant for this particular use case, but it's still a sign that the > construction is bad. > > 3. The SHA hashes, like all Merkle-Damgård hashes, is subject to > length-extension attacks. In particular, if x is a multiple (or slightly > above > a multiple) of the block length, then anyone who learns SHA(x) can efficiently > derive SHA(x || k). This basically removes all security from this scheme. > > HMAC(k, x) would be much better. > > But I think this protocol is generally more fragile then needed. How about > generating a per-app-installation random value and HMAC-ing *that* with the > machine id? I think this is extreme overkill for something that doesn't need to be cryptographically sound. It literally just needs to be eight characters with a sensible random distribution. I considered using some non-reversible transformation of machine-id for this simply because I wanted to avoid trying to consume any of the entropy in /dev/random since we'd be doing this early in the installer (when entropy tends to be at a premium). Maybe that was overkill and I should just pull from /dev/random. I can't think of a reason why we'd need a cryptographically secure transformation just to generate a random hostname. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 11/11/2016 12:08 PM, Lennart Poettering wrote: > On Fri, 11.11.16 11:12, Stephen Gallagher (sgall...@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 realize that some of this is coming from my old-school sensibilities, but I still remember a time when changing the hostname of a running system caused lots of things to fail, including NFS and sendmail. Changing the enrolling code to modify the machine's hostname would be very unexpected from an end-user perspective, don't you think? >> * 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) > See child reply. I was trying to spare us some entropy during early setup, but I can't think of any reason this needs to be any more complicated than something fed from /dev/random if we aren't going to try to generate it early in the install process. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 11/11/2016 9:08 AM, Lennart Poettering wrote:
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".
Given the text of RFC6761
[https://tools.ietf.org/html/rfc6761#section-6.3], something like
"fedora-XX.localhost" would also be an option, if we absolutely
needed a domain component. ("localdomain." seems like a not-invisible
number of root TLD lookups at http://stats.dns.icann.org/hedgehog/). But
a simple "localhost" seems a sufficient default over this localdomain.
redhatism.
On 11/11/2016 6:50 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Nov 11, 2016 at 12:13:48PM -, fred...@rambris.com wrote:
I like Fedora- for default hostname. If I don't care to set a hostname
it would be an ok hostname for my machine. I would however like if the hostname
setting would be more prominent in the installer. Possibly generating based on
my name along the lines of: fredriks-laptop.rambris.lan
Making the choice it more prominent is probably not necessary, if we
provide a nice default. Although it probably wouldn't hurt. The hostname
could be displayed in the summary or maybe the user creation dialogue
('Create user "user1@Fedora-123345"'?).
Anaconda having a distinct panel explicitly for setting the hostname,
along with some knobs for setting the default, depending, for example,
on if we've already gotten an IP during PXE, would be a good thing IMO.
Prompts and options would help with some kickstart situations, where one
would like a chance to permanently specify it during install regardless
of user accounts or install-time networking, and before we reboot for
the first time.
-jc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Fri, 11.11.16 13:23, Stephen Gallagher (sgall...@redhat.com) wrote: > > 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 realize that some of this is coming from my old-school sensibilities, but I > still remember a time when changing the hostname of a running system caused > lots > of things to fail, including NFS and sendmail. Well, we support changing hostnames dynamically through DHCP just fine these days. The kernel has a proper API to be notified about hostname changes these days (just poll() on /proc/sys/kernel/hostname), and because of nss-myhostname it always stays resolvable, instantaneously when you change it. I am pretty sure most things should work just fine, at least in the base OS. Sure, some higher level services might be broken still, but I'd suggest to fix that instead of never changing the hostname... > Changing the enrolling code to modify the machine's hostname would be very > unexpected from an end-user perspective, don't you think? I don't think so... I mean, enrollment is interactive anyway, no? it could display a warning "your hostname is crap, will now change it for you to xyz, unless you have something better which you can type in here"... or so? > See child reply. I was trying to spare us some entropy during early setup, > but I > can't think of any reason this needs to be any more complicated than something > fed from /dev/random if we aren't going to try to generate it early in the > install process. Well, deriving this from the machine ID automatically has the benefit that you don't have to store your ID anywhere. And that's actually a very important property if you want your stuff to work properly in environments where systems are installed via disk images instead of anaconda (which I'd claim is pretty often done in the wild these days, and is the basic concept up container bundles after all): many provisioning tools these days are smart enough to reset the machine ID before deploying an image, but patching through all of them to also reset the IPA ID is going to be hard (and honestly: I doubt this would even be desirable). I am pretty sure: if local services need unique IDs somewhere, then please base them on /etc/machine-id, so that resetting the machine-id will reset them too, and knowing the machine-id is enough to know all app-specific IDs of the system too. However, never expose /etc/machine-id as-is on any untrusted place, please always derive the ID you use in a cryptographically secure way from it, which cannot be reversed... Lennart -- Lennart Poettering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
Once upon a time, Andrew Lutomirski said: > NetworkManager already has the ability to randomize MAC addresses to keep > them from leaking. "has the ability" is not "on by default". If you want that level of anonymity, you have to turn it on. Also then changing your hostname, enabling an option to not send it, etc. is not a big deal (or could even be part of a combined "anonymize me" checkbox). This is about the default hostname; that configuration should be at the same level as other default options. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 11 November 2016 at 13:23, Stephen Gallagher wrote: >> 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 realize that some of this is coming from my old-school sensibilities, but I > still remember a time when changing the hostname of a running system caused > lots > of things to fail, including NFS and sendmail. > > Changing the enrolling code to modify the machine's hostname would be very > unexpected from an end-user perspective, don't you think? > Doesn't an AD environment do that though through group policies. I can call my machine 'screw-the-boss' and after it gets registered into the AD it becomes whatever the corporate policy says it will be 'windows-1138' [Or at least the place I had AD had something in their system to do that so that students who thought that having hostnames of curse words or worse couldn't keep them if they enrolled the system into AD] And yes certain things might fail because the hostname changes.. but you restart them or reboot. We all like rebooting don't we :)? > > >>> * 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) >> > > See child reply. I was trying to spare us some entropy during early setup, > but I > can't think of any reason this needs to be any more complicated than something > fed from /dev/random if we aren't going to try to generate it early in the > install process. Just use /dev/urandom. If you use /dev/random then someone is going to assume you meant it to be cryptographically secure and come up with a method which is better. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Fri, Nov 11, 2016 at 12:46:43PM -0600, Chris Adams wrote: > Once upon a time, Andrew Lutomirski said: > > NetworkManager already has the ability to randomize MAC addresses to keep > > them from leaking. > > "has the ability" is not "on by default". If you want that level of > anonymity, you have to turn it on. Also then changing your hostname, > enabling an option to not send it, etc. is not a big deal (or could even > be part of a combined "anonymize me" checkbox). Yes, I think it makes a lot of sense to expose both under the same configuration switch. Sending the hostname while randomizing MAC address or vice versa just isn't useful. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Fri, Nov 11, 2016 at 01:20:26PM -0500, Stephen Gallagher wrote: > On 11/11/2016 12:17 PM, Andrew Lutomirski wrote: > > /me dons crypto hat. > > > > SHA(x || k) has three problems, one of which is bad enough to be an absolute > > showstopper. > > > > 1. Specify *which* SHA. SHA-1 should not be used for new applications. > > > > 2. Concatenation without some additional property preventing collisions of > > the > > hashed data is problematic. In particular, if you shorten x by a byte and > > prepend the same byte to k, you get the same output. This is probably > > irrelevant for this particular use case, but it's still a sign that the > > construction is bad. > > > > 3. The SHA hashes, like all Merkle-Damgård hashes, is subject to > > length-extension attacks. In particular, if x is a multiple (or slightly > > above > > a multiple) of the block length, then anyone who learns SHA(x) can > > efficiently > > derive SHA(x || k). This basically removes all security from this scheme. > > > > HMAC(k, x) would be much better. Thanks, that's something to take into consideration. > > But I think this protocol is generally more fragile then needed. How about > > generating a per-app-installation random value and HMAC-ing *that* with the > > machine id? > > I think this is extreme overkill for something that doesn't need to be > cryptographically sound. It literally just needs to be eight characters with a > sensible random distribution. I considered using some non-reversible > transformation of machine-id for this simply because I wanted to avoid trying > to > consume any of the entropy in /dev/random since we'd be doing this early in > the > installer (when entropy tends to be at a premium). Maybe that was overkill > and I > should just pull from /dev/random. There's one advantage to deriving the hostname from machine-id: it is predictable and will always be generated the same. Usually this will not matter, but if /etc is readonly we might no be able to save the hostname. > I can't think of a reason why we'd need a cryptographically secure > transformation just to generate a random hostname. We want it cryptographically secure to preserve the machine-id. It's probably not too important in itself, but it's a good idea to keep it hidden because other hashes might be generated from it. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 11 November 2016 at 22:20, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Nov 11, 2016 at 01:20:26PM -0500, Stephen Gallagher wrote: >> I can't think of a reason why we'd need a cryptographically secure >> transformation just to generate a random hostname. > > We want it cryptographically secure to preserve the machine-id. It's > probably not too important in itself, but it's a good idea to keep > it hidden because other hashes might be generated from it. 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. Trying to find some happy middle ground ends up usually with it pouring out all at once when no one expected it. > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Sat, Nov 12, 2016 at 11:17:39AM -0500, Stephen John Smoogen wrote: > On 11 November 2016 at 22:20, Zbigniew Jędrzejewski-Szmek > wrote: > > On Fri, Nov 11, 2016 at 01:20:26PM -0500, Stephen Gallagher wrote: > > >> I can't think of a reason why we'd need a cryptographically secure > >> transformation just to generate a random hostname. > > > > We want it cryptographically secure to preserve the machine-id. It's > > probably not too important in itself, but it's a good idea to keep > > it hidden because other hashes might be generated from it. > > 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. > Trying to find some happy middle ground ends up usually with it > pouring out all at once when no one expected it. True. But one, it's not *that* important, it's not the root password or anything. But two, it'd say that we're designing it to drip out very very slowly. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 12 November 2016 at 13:14, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Nov 12, 2016 at 11:17:39AM -0500, Stephen John Smoogen wrote: >> On 11 November 2016 at 22:20, Zbigniew Jędrzejewski-Szmek >> wrote: >> > On Fri, Nov 11, 2016 at 01:20:26PM -0500, Stephen Gallagher wrote: >> >> >> I can't think of a reason why we'd need a cryptographically secure >> >> transformation just to generate a random hostname. >> > >> > We want it cryptographically secure to preserve the machine-id. It's >> > probably not too important in itself, but it's a good idea to keep >> > it hidden because other hashes might be generated from it. >> >> 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. >> Trying to find some happy middle ground ends up usually with it >> pouring out all at once when no one expected it. > > True. But one, it's not *that* important, it's not the root password > or anything. But two, it'd say that we're designing it to drip out very > very slowly. Until someone decides that deriving the root password from the machine-id is a good idea. In the end, I have said my piece.. you guys have fun. > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Friday, November 11, 2016 11:12:51 AM CST Stephen Gallagher wrote: > 3) My original proposal was: change the fallback name to Fedora- by > default, while of course retaining the ability to set it manually. I think this is terrible, Just because if you are on a system with a small resoultion, say 800x600 the command prompt will take up half the screen. > 4) The specific issue relating to FreeIPA and Active Directory is one of > uniqueness: you can only have one machine named "localhost" enrolled in a > domain. A user who is unaware of the hostname at all will not know to change > it ahead of time. can we add a flag to set the hostname at enrollment time? I guess I am unusual in setting all of my host names at install/initial configuration time. Dennis signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 12/11/16 20:02, Dennis Gilmore wrote: On Friday, November 11, 2016 11:12:51 AM CST Stephen Gallagher wrote: 3) My original proposal was: change the fallback name to Fedora- by default, while of course retaining the ability to set it manually. I think this is terrible, Just because if you are on a system with a small resoultion, say 800x600 the command prompt will take up half the screen. Now this is true. Why not just "fedora-(version number)"? That's short, simple and says almost nothing about the computer. Cheers, Sylvia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 11/11/16 19:23, Stephen Gallagher wrote: I realize that some of this is coming from my old-school sensibilities, but I still remember a time when changing the hostname of a running system caused lots of things to fail, including NFS and sendmail. Well... many times I forget to set hostname during installation and when I do it afterwards nothing happens. So I guess those fails aren't applicable today. Cheers, Sylvia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 11/11/16 19:38, Lennart Poettering wrote: I am pretty sure most things should work just fine, at least in the base OS. Sure, some higher level services might be broken still, but I'd suggest to fix that instead of never changing the hostname... Changing the enrolling code to modify the machine's hostname would be very unexpected from an end-user perspective, don't you think? I don't think so... I mean, enrollment is interactive anyway, no? it could display a warning "your hostname is crap, will now change it for you to xyz, unless you have something better which you can type in here"... or so? This made my day... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
Since I like to use terminal a lot, I would prefer if you keep it short! If you must include branding I would prefer shorter version of "Fed" or "fed" so ideally something like "fed12345". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
> Since I like to use terminal a lot, I would prefer if you keep it short! > > If you must include branding I would prefer shorter version of "Fed" or > "fed" so ideally something like "fed12345". Shorter hostname is not only useful when typing commands, but anywhere else where it is used. For example journalctl logs. You don't want hostname to take half of the screen? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 11/12/2016 01:14 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Nov 12, 2016 at 11:17:39AM -0500, Stephen John Smoogen wrote: >> On 11 November 2016 at 22:20, Zbigniew Jędrzejewski-Szmek >> wrote: >>> On Fri, Nov 11, 2016 at 01:20:26PM -0500, Stephen Gallagher wrote: >> I can't think of a reason why we'd need a cryptographically secure transformation just to generate a random hostname. >>> >>> We want it cryptographically secure to preserve the machine-id. It's >>> probably not too important in itself, but it's a good idea to keep >>> it hidden because other hashes might be generated from it. >> >> 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. >> Trying to find some happy middle ground ends up usually with it >> pouring out all at once when no one expected it. > > True. But one, it's not *that* important, it's not the root password > or anything. But two, it'd say that we're designing it to drip out very > very slowly. One way to address this might be for systemd to provide an API for what Lennart is suggesting and market that as "the correct way to generate a machine-id-derived string". Basically, I see the function looking something like: ``` 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.) Then systemd can control the cryptographic hash. If this function exists and is public, then people will generally be inclined to use it and we will minimize the number of people who opt to try to write their own or use the machine-id directly. I will file an RFE. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Mon, 14.11.16 08:13, Stephen Gallagher (sgall...@redhat.com) wrote: > One way to address this might be for systemd to provide an API for what > Lennart > is suggesting and market that as "the correct way to generate a > machine-id-derived string". > > Basically, I see the function looking something like: > > ``` > 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.) > > > Then systemd can control the cryptographic hash. If this function exists and > is > public, then people will generally be inclined to use it and we will minimize > the number of people who opt to try to write their own or use the machine-id > directly. > > I will file an RFE. That sounds like a good idea, I think it would make a lot of sense for libsystemd to expose an API to generate an app-specific machine id. (though I'd stick to 128bit ids for both the app key and the result). Lennart -- Lennart Poettering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 11/14/2016 09:05 AM, Lennart Poettering wrote: > On Mon, 14.11.16 08:13, Stephen Gallagher (sgall...@redhat.com) wrote: > >> One way to address this might be for systemd to provide an API for what >> Lennart >> is suggesting and market that as "the correct way to generate a >> machine-id-derived string". >> >> Basically, I see the function looking something like: >> >> ``` >> 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.) >> >> >> Then systemd can control the cryptographic hash. If this function exists and >> is >> public, then people will generally be inclined to use it and we will minimize >> the number of people who opt to try to write their own or use the machine-id >> directly. >> >> I will file an RFE. > > That sounds like a good idea, I think it would make a lot of sense for > libsystemd to expose an API to generate an app-specific machine > id. (though I'd stick to 128bit ids for both the app key and the result). https://github.com/systemd/systemd/issues/4667 signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On Pá, 2016-11-11 at 13:20 -0500, Stephen Gallagher wrote: > I think this is extreme overkill for something that doesn't need to > be > cryptographically sound. It literally just needs to be eight > characters with a > sensible random distribution. I considered using some non-reversible > transformation of machine-id for this simply because I wanted to > avoid trying to > consume any of the entropy in /dev/random since we'd be doing this > early in the > installer (when entropy tends to be at a premium). Maybe that was > overkill and I > should just pull from /dev/random. Please, please, do not mention use of /dev/random at all. Use /dev/urandom. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 11.11.2016 19:25, Japheth Cleaver wrote:
> On 11/11/2016 9:08 AM, Lennart Poettering wrote:
>> 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".
>
> Given the text of RFC6761 [https://tools.ietf.org/html/rfc6761#section-6.3],
> something like "fedora-XX.localhost" would also be an option, if we
> absolutely needed a domain component. ("localdomain." seems like a
> not-invisible number of root TLD lookups at
> http://stats.dns.icann.org/hedgehog/). But a simple "localhost" seems a
> sufficient default over this localdomain. redhatism.
I support his. We should use .localhost so RFC6761 applies and
Fedora boxes do not pollute DNS infrastructure with nonsensical requests
nobody can answer.
Petr^2 Spacek
>
>
> On 11/11/2016 6:50 AM, Zbigniew Jędrzejewski-Szmek wrote:
>> On Fri, Nov 11, 2016 at 12:13:48PM -, fred...@rambris.com wrote:
>>> I like Fedora- for default hostname. If I don't care to set a
>>> hostname it would be an ok hostname for my machine. I would however like if
>>> the hostname setting would be more prominent in the installer. Possibly
>>> generating based on my name along the lines of: fredriks-laptop.rambris.lan
>> Making the choice it more prominent is probably not necessary, if we
>> provide a nice default. Although it probably wouldn't hurt. The hostname
>> could be displayed in the summary or maybe the user creation dialogue
>> ('Create user "user1@Fedora-123345"'?).
>
> Anaconda having a distinct panel explicitly for setting the hostname, along
> with some knobs for setting the default, depending, for example, on if we've
> already gotten an IP during PXE, would be a good thing IMO.
>
> Prompts and options would help with some kickstart situations, where one would
> like a chance to permanently specify it during install regardless of user
> accounts or install-time networking, and before we reboot for the first time.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
- Original Message - > Further, from a purely technical perspective, I think I've been swayed by > arguments around the generation of the hostname: > > * I'm fine with the lowercase "fedora-" prefix. It makes sense since > hostnames > are generally normalized to lower-case in common usage. > > * 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. > > > > For Anaconda folks: would it be possible to have the currently-selected > hostname > be visible next to the "Networking" spoke on the main hub page? You show the > selected environment group beside the "Software Selection" spoke and the > connected network device, so it might be useful to let people know what the > hostname is as well. (This would also be handy if it turns out that DHCP is > trying to assign a hostname; the user may not want or expect that) As mentioned in the fedora-desktop thread about branding, I don't like seeing this sort of randomly generated and nonsensical (and I mean that in that a string of hex characters obviously don't *mean* something) shouldn't be user-visible. Right now, you'd see the hostname on the machine itself in the Sharing and Details panels in GNOME, in bash's prompt, and in quite a few remotely accessible services (the Bluetooth name, shared media, ssh, etc.). There's nothing stopping us from having a hidden/secondary hostname though, and a randomly generated one would fit perfectly for this sort of use case. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC (round 2): Change the default hostname for Fedora 26+
On 15 Nov 2016, at 11:37, Bastien Nocera wrote: As mentioned in the fedora-desktop thread about branding, I don't like seeing this sort of randomly generated and nonsensical (and I mean that in that a string of hex characters obviously don't *mean* something) shouldn't be user-visible. Right now, you'd see the hostname on the machine itself in the Sharing and Details panels in GNOME, in bash's prompt, and in quite a few remotely accessible services (the Bluetooth name, shared media, ssh, etc.). There's nothing stopping us from having a hidden/secondary hostname though, and a randomly generated one would fit perfectly for this sort of use case. Now that would be confusing for users -- a hidden name that bears no relation to the exposed name. -- Mike ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
