On Tue, 2022-01-25 at 00:54 -0600, Richard Laager wrote: > > There are two potential issues: > A) the server serves bogus/malicious time > B) a MITM messes with the time.
Yes,... (B) should be rather difficult with NTS (well the X.509 CA system is inherently broken, and I'd guess it's rather "easy" to get a forged cert... but that's another topic - and at least one can specify a single cert per server... so it can be made quite secure). (A) is kinda what I'd want to prevent by having -g removed... at least it shouldn't be "so easy" anymore for a rogue server (NTS or not) to quickly change the time by amounts that really matter. > The primary protection for A is consensus (see specifically minsane). > A > single bogus/malicious clock can't do anything. At least not quickly... AFAIU it should still be able to slowly change my time, over time. But intuitively I'd also say, that this increases the chances of noticing the attack. Not if the attacker's goal is to shift my time by 3 minutes or so... but for any larger times, one could sooner or later notice it (that is: on desktop systems - but for anyone who really needs tight time security on servers, there are probably anyway other measures to be taken). > But yes, without NTS and with -g (both being the defaults in Debian), > ultimately a MITM could adjust all of the times you're seeing and set > any time, but only once upon boot. Eliminating -g would improve > security in this situation. But there are trade-offs. But IMO even with NTS. I get my time from some triple-letter-agency,... no not the CIA but PTB (less something like the CIA, but more comparable to NIST ... and Germany's official time provider). With -g, and even despite NTS, they could send me malicious time, every time I boot (or (re)start the service manually). > That's true until it isn't: one day your motherboard's battery dies > and > now your clock is wrong, despite running ntpd. Sure... but still it's a conceptual question what one wants: If one installs ntpsec, rather than just ntp or systemd-timesync ... and at least if one uses NTS,... then the intention is probably to get secure time. Conceptually I'd say, that in such situation, if the battery dies, I'd rather get failure on starting (which one could at least detect and e.g. send some mail notification). > > OTOH, embedded systems are "special" and if someone uses a system > > with > > no clock at all, than IMO it's rather his duty to take necessary > > steps > > so that it works (e.g. by installing ntpdate). > > I'm not sure how installing ntpdate is different from installing > ntpsec > in that regard. I meant for the case that ntpsec would drop "-g" per default, and then possibly no longer be able to give time to such systems. The same conceptual question comes up as above. Let's use another example for it: embedded systems often have bad RNG sources (or at least their initial seeding takes long). If e.g. SSH is used, than people expect things to be secure. Thus one rather lets SSH fail or block (until enough entropy has been collected) instead of letting it use bad random numbers - even, if then things don't work so out-of-the-box anymore. The same would IMO apply to a service like ntpsec, which one typically installs for exactly the reason of being (more) secure. > Let's say I remove -g by default. (Then I can safely set > Restart=on-failure by default.) I could address some/all of the > trade-offs: > > I'd imagine I could script up something to add -g on the first run of > ntpd on initial install, to address that case. For example, I could > detect the first run scenario as there being no drift file. Maybe one could add some debconf dialog, that just shows the "previous" time, and in comparison the time after it was first (and once) set with -g. > I could use hwclock(1) to determine if there is an RTC. If not, add - > g. > That would make the Raspberry Pi case work out-of-the-box without > decreasing security for regular systems. Similarly, I'd recommend a debconf question here (which is e.g. only asked if no RTC is found). > That still leaves the case of "my RTC battery died". I could probably > detect that too, by checking to see if the current time is older than > the drift file, and again add -g. I don't see much what one could do here (apart perhaps from sending mail to root, but that would require someone to actually read this). Also, any automagical configuration changes (after initial installation )are IMO rather no so advisable. I guess that's simply a risk that comes with using secured NTP. It's similar to when I hardcode a root CA or server cert for some time source - I must live with the fact that it could change respectively expire. One could perhaps ask (yet another) debconf question, asking whether -g should be added, describing the case of e.g. dying RTC battery while also explaining the risks of enabling this. > The only problem I see with this is that if I'm adding -g under > various > circumstances, there's then no way for the administrator to prohibit > -g. Which would defeat the whole purpose. > Another option would be to remove -g from $NTPD_OPTS if none of those > conditions apply. If I'm only removing -g, the admin can still ensure > -g > is not used by removing it. But then we'd again have the "not-so-secure-out-of-the-box" situation. Extremely exaggerated: ;-) As if SSH would default do: Oh you don't have verified your remote public key? Well just accept it blindly, because everything else would mean it doesn't work out-of-the-box. > This creates the opposite problem: there's > no way for an admin to add -g if they want it always. (Unless my -g > removal only removes one and they set NTPD_OPTS="-g -g" but that > seems > like a hack.) But, removing options is itself tricky (e.g. > NTPD_OPTS="-gN" or NTPD_OPTS="-Ng") and that feels like asking for > trouble. One could add another option, that controls whether your script are allowed (or not) to automatically add -g. But as said... any automagical things are IMO quite suspect. I'd then rather just ask debconf questions, choosing secure defaults (which would IMO be not using -g or DHCP in any case, regardless of no- RTC/battery/etc. - simply for the sake of the purpose of ntpSEC ). That would still allow an easy override... and even to script that. > Really, ntpsec-ntpdate should just die and this gets simpler. ;-) > That said, if I'm using NTS in my ntp.conf, that's being defeated by > the > DHCP integration. That's probably a good reason to disable DHCP > integration by default. Yes... I'd really leave that just in for e.g. server farms, which trust their own network and DHCP to give them a proper time source. But even then.... for any such big site, they probably have some configuration management in place and it may be easier to set the time source directly in ntp.conf via that... instead of indirectly via DHCP. I always hated (and considered it quite security questionable) how much DHCP is allowed to modify. E.g. it doesn't seem to be possible to forbid it setting the DNS search key. Cheers, Chris.
