Re: [systemd-devel] Setting UseDomains=yes by default DHCP
It seems this thread was already resolved, just wanted to add one comment: On Mon, May 18, 2015 at 2:26 PM, Zbigniew Jędrzejewski-Szmek wrote: > So to mount a successful spoof, the attacker needs to > a) control the dhcp server domain option to return a domain under attacker > control Notice that this is entirely trivial, as the attacker does not need to control _the_ DHCP server, all they have to do is to provide a competing DHCP server on the local link and hope they get picked over the real one. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Setting UseDomains=yes by default DHCP
On Tue, 19.05.15 02:37, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > On Mon, May 18, 2015 at 07:33:43PM +0200, Lennart Poettering wrote: > > On Mon, 18.05.15 12:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > > > I now agree with what Lennart proposed too. This is partially implemented > > > now, and with UseDomains=yes, option 15 is used to to set 'search' field. > > > > > > I think we should go a step further, and set UseDomains=yes by default, > > > to have 'search' populated in /etc/resolv.conf. I think the security > > > reservations are overstated: > > > iiuc, the concern was that multi-level domain names (i.e. those with at > > > least > > > one dot) could be spoofed by controlling the search suffix. But for > > > names with at least two levels glibc only uses the search list as a > > > fallback. > > > > Well, sure, being able to influence things at the beginning of the > > search logic is more problematic than influencing things at the end of > > the search logic, but i still think it's problematic, since it still > > allows you to insert "home.foobar.com" into a domain "foobar.com" that > > doesn't have "home.foobar.com" itself but only "www.bar.com"... > > > > Sure, classic (non-DNSSEC) DNS is not ever going to be fully secure, > > but it I still believe we should default to the safer options, and > > allow the others. > > > > Altering the search paths is inherently something that makes no sense > > on public networks, it only makes sense if you know your network well, > > and trust it to some level. Hence opt-in sounds like the better option > > to me. > > Ok, this makes a lot of sense... but currently this policy is not very > consistent. UseDNS defaults to true, which gives control of *all* names > to the dhcp server, not just over the prefix. When we have DNSSEC by default, > this will be different though, so that's fine I guess. > > OTOH, I really don't see why UseHostname default to true. Why trust the > server in this regard? Well, we use it to initialize the "transient" hostname managed by hostnamed with. And the "transient" hostname is irrelevant if there's a static one defined, since the static hostname overrides the transient one. or in other words: usehostname has only very weak effects: it propagates to the kernel hostname only if you have no manual configuration... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Setting UseDomains=yes by default DHCP
On Mon, May 18, 2015 at 07:33:43PM +0200, Lennart Poettering wrote: > On Mon, 18.05.15 12:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > I now agree with what Lennart proposed too. This is partially implemented > > now, and with UseDomains=yes, option 15 is used to to set 'search' field. > > > > I think we should go a step further, and set UseDomains=yes by default, > > to have 'search' populated in /etc/resolv.conf. I think the security > > reservations are overstated: > > iiuc, the concern was that multi-level domain names (i.e. those with at > > least > > one dot) could be spoofed by controlling the search suffix. But for > > names with at least two levels glibc only uses the search list as a > > fallback. > > Well, sure, being able to influence things at the beginning of the > search logic is more problematic than influencing things at the end of > the search logic, but i still think it's problematic, since it still > allows you to insert "home.foobar.com" into a domain "foobar.com" that > doesn't have "home.foobar.com" itself but only "www.bar.com"... > > Sure, classic (non-DNSSEC) DNS is not ever going to be fully secure, > but it I still believe we should default to the safer options, and > allow the others. > > Altering the search paths is inherently something that makes no sense > on public networks, it only makes sense if you know your network well, > and trust it to some level. Hence opt-in sounds like the better option > to me. Ok, this makes a lot of sense... but currently this policy is not very consistent. UseDNS defaults to true, which gives control of *all* names to the dhcp server, not just over the prefix. When we have DNSSEC by default, this will be different though, so that's fine I guess. OTOH, I really don't see why UseHostname default to true. Why trust the server in this regard? > > The story is sligthly different for single-level names. By setting > > UseDomains=yes > > we allow the dhcp server some control over the resolution of those names. > > But that seems natural too. If we want to allow LLMR or avahi, allowing > > the dhcp server to also control local name resolution seems a natural > > extension. > > > > Any reservations for making UseDomains=yes the default? > > I'd really prefer if this stays opt-in. That said, I think it would be > a really good idea to improve the documentation of DHCP= to suggest > people to set UseDomains=yes if they need it. I now pushed a commit which does that. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Setting UseDomains=yes by default DHCP
On Mon, 18.05.15 12:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > I now agree with what Lennart proposed too. This is partially implemented > now, and with UseDomains=yes, option 15 is used to to set 'search' field. > > I think we should go a step further, and set UseDomains=yes by default, > to have 'search' populated in /etc/resolv.conf. I think the security > reservations are overstated: > iiuc, the concern was that multi-level domain names (i.e. those with at least > one dot) could be spoofed by controlling the search suffix. But for > names with at least two levels glibc only uses the search list as a > fallback. Well, sure, being able to influence things at the beginning of the search logic is more problematic than influencing things at the end of the search logic, but i still think it's problematic, since it still allows you to insert "home.foobar.com" into a domain "foobar.com" that doesn't have "home.foobar.com" itself but only "www.bar.com"... Sure, classic (non-DNSSEC) DNS is not ever going to be fully secure, but it I still believe we should default to the safer options, and allow the others. Altering the search paths is inherently something that makes no sense on public networks, it only makes sense if you know your network well, and trust it to some level. Hence opt-in sounds like the better option to me. > The story is sligthly different for single-level names. By setting > UseDomains=yes > we allow the dhcp server some control over the resolution of those names. > But that seems natural too. If we want to allow LLMR or avahi, allowing > the dhcp server to also control local name resolution seems a natural > extension. > > Any reservations for making UseDomains=yes the default? I'd really prefer if this stays opt-in. That said, I think it would be a really good idea to improve the documentation of DHCP= to suggest people to set UseDomains=yes if they need it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
