On Tue, 2022-01-18 at 21:52 -0600, Richard Laager wrote: > > Shouldn't -g be removed? > > First off, note that the stock ntpsec.service has Restart=no, not > Restart=yes. So in the malicious/broken server scenario described, > ntpd > will die, but not restart.
How does that add protection? Isn't it still, that if one e.g. reboots and ntpd starts the first time, then an attacker could basically set any time? > As far as -g goes, there's really no one right answer. If you keep - > g, > then ntpsec can fix arbitrarily broken clocks. If you remove it, then > it > can't. Imagine how confusing would be if you clock is wrong, you > install > ntpsec, and your clock is still wrong. Additionally, consider systems > like the Raspberry Pi where there is no real-time clock; they need > ntpd > to be able to make large adjustments, so removing -g would break > them. One could argue here, that most "normal" systems (desktops, servers) have usually rather well working clocks... an so they wouldn't be likely affected by what you describe. 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). Someone who installs ntpsec probably goes for the "sec" part... and it feels as if security would be weakened quite a bit by having -g or allowing DCHP advertised clocks per default, just in order to make things more runs-out-of-the-box. > Users can override the -g default in /etc/default/ntpsec and/or the > Restart=no default with a systemd drop-in file. FWIW, at my day job, > I > override both on non-Pi always-on server systems: I set NTPD_OPTS="- > N" > (no -g) and Restart=on-failure. On Raspberry Pis, I keep -g and still > set Restart=on-failure, but I'm not doing anything security sensitive > on > Pis. Those settings mean that ntpd will get restarted if it crashes > (not > that I've ever seen it crash). Again,... seems like if security would be weakened for use cases where security isn't that important anyway (and ntpsec itself isn't that crucial). > > 2) Also in /etc/default/ntpsec, per default IGNORE_DHCP is "". > > Shouldn't that be set to yes, so that per default a malicious DHCP > > server > > couldn't add it's own possible rogue servers? > > Maybe. But ntpsec-ntpdate isn't installed by default and even > installing > ntpsec doesn't pull it in. If you choose to install that package, you > (arguably) are expressing a desire to use its features, and the DHCP > integration is a big part of that. I didn't realise that /etc/default/ntpsec's IGNORE_DHCP actually affects only ntpsec-ntpdate (or at least that's how I understand you)... which however has it's own /etc/default file with it's own IGNORE_DHCP?? > > 3) The legacy ntp.conf used: > > restrict -4 default kod notrap nomodify nopeer noquery limited > > restrict -6 default kod notrap nomodify nopeer noquery limited > > > > okay, notrap is gone > > This was removed from the Debian ntp.conf (commit from ntpsec-pkg, > not > upstream): That's what I've meant with my "is gone" :-) > docs/access.adoc (in the source), which compiles to > /usr/share/doc/ntpsec-doc/html/access.html in ntpsec-doc, says: > +restrict default+, with no mask option, modifies both IPv4 and IPv6 > default entries. Ah I see. > So it should apply to both. If you have any reason to believe it's > not > working for both, please let me know. No, not apart from those links I've sent before. Thanks for your help :-) Chris.
