Bug#1003956: ntpsec: security settings

2022-01-25 Thread Richard Laager
On 1/25/22 17:08, Christoph Anton Mitterer wrote: On Tue, 2022-01-25 at 16:34 -0600, Richard Laager wrote: Consider a powerful attacker who a) runs a clocksource one trusts and b) can block traffic to any other sources in the pool one uses? Does NTP(sec) complain eventually (like too many source

Bug#1003956: ntpsec: security settings

2022-01-25 Thread Christoph Anton Mitterer
On Tue, 2022-01-25 at 16:34 -0600, Richard Laager wrote: > > At least not quickly... AFAIU it should still be able to slowly > > change > > my time, over time. > > I don't see how that's possible. Eventually that single server will > tick > too far outside of the consensus window and be excluded

Bug#1003956: ntpsec: security settings

2022-01-25 Thread Richard Laager
On 1/25/22 10:45, Christoph Anton Mitterer wrote: 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. (A) is kinda what I'd want to prevent by having -g removed... at least it shoul

Bug#1003956: ntpsec: security settings

2022-01-25 Thread Christoph Anton Mitterer
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 "eas

Bug#1003956: ntpsec: security settings

2022-01-24 Thread Richard Laager
Control: reopen -1 On 1/24/22 13:25, Christoph Anton Mitterer wrote: 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

Bug#1003956: ntpsec: security settings

2022-01-24 Thread Christoph Anton Mitterer
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'

Bug#1003956: ntpsec: security settings

2022-01-18 Thread Christoph Anton Mitterer
Package: ntpsec Version: 1.2.1+dfsg1-2 Severity: normal Hey. I wondered the following: 1) In the systemd unit file, it's commented: # Specifying -g on the command line allows ntpd to make large adjustments to # the clock on boot. However, if Restart=yes is set, a malicious (or broken) # serve