Re: [gpsd-dev] Updated docs on NTP segment management

[Harlan Stenn]

It's been a while since I looked at the SHM stuff.

I thought that there was a time when the two sides did some sort of
"handshake" thru the SHM segment, and that was apparently useful to let
each side know the other side was paying attention.

If there is no reason for this anymore, cool, and that means that it's
fine for the "consumer" to have read-only access.

I remember (perhaps correctly) that one of the reasons either ntpd or
the "provider" of time could open the SHM segment was to avoid startup
ordering problems.

I can see the bit of danger if the segment is 666, and part of me
wonders how dangerous that really is.  On the one hand, 666 gives a
cracker a way to mess with time and make more progress on their attack.
This is bad.  OTOH, and my lack of infosec paranoia is showing, what's
the cost/benefit layout of making it that much harder for anybody to
write to the segment?  How much of a hurdle is it for a bad actor to
get write access to a 660 SHM segment, or 6xx access?

How difficult would it be (I'm not saying it's a good idea) to write a
program that monitors the SHM segment and alerts when it seems that
something nefarious is going on?  It seems to me that such a program
would be a big waste of time/effort, but hey, if you're at tangible risk
for somebody messing with *any* malicious writing to the SHM time
segment, it might be worth it.

And I still need to get ESR's comments added to:

 http://support.ntp.org/bin/view/Dev/RefclockShmV2

H