In case anybody isn't familiar with this area... The idea is to tell the system that this program will only use a specified list of system calls. If a bad guy finds something like a stack overflow, their evil code can only use those calls. Seems like a useful tool to add to the collection.
It's Linux only. apropos seccomp has details. We only use seccomp_init, seccomp_rule_add, and seccomp_load. The problem is that there is no simple way to translate a POSIX call to a kernel call. There is libc and friends between what ntpd does and the actual system calls. Sometimes, that's simple. Sometimes it's complicated. If varies between distros and releases. The current list is collected by trial and error. When I found a syscall that was legitimately used, I added it to the list. For any given system, there are probably some calls allowed that are not used. There may be edge cases that just haven't been tested yet - either new versions of libc or corners of the code on familiar systems. For an example, see issue #275. It seems unlikely to me that this will ever converge. Most of the time it is easy to fix. On the other hand, maybe it is a useful tool. We can probably get it working well enough for any distro with a significant number of users/testers. There are 2 chunks of code that account for a lot of the problems. If somebody is looking for more security, we could run with fewer syscalls enabled by disabling some features. One is DNS lookup. We could trim the list if we disabled DNS lookups, or did them early. This would mean no support for the pool command in ntp.conf. But it would be reasonable for a low stratum carefully managed server. The other area is interfaces coming and going. This is normal for a laptop using wifi which goes to sleep with one IP Address and gets a new one when it wakes up in a new location. I think Fedora and/or Debian restart ntpd in that case, but that shouldn't be necessary. It also happens if you unplug an ethernet cable, and presumable if the switch gets power cycled. I think we should be able to fix this, probably as part of a great interface cleanup. In case it isn't obvious, I think this is pretty far down in the weeds. >From unplugging and replugging an ethernet cable: 8 May 14:47:22 ntpd[28281]: Deleting interface #3 eth0, 192.168.1.30#123, interface stats: received=45188, sent=45289, dropped=0, active_time=217285 secs 8 May 14:47:22 ntpd[28281]: Deleting interface #5 eth0, fe80::21d:72ff:feb3:a5d2%2#123, interface stats: received=8816, sent=8816, dropped=0, active_time=217285 secs 8 May 14:47:22 ntpd[28281]: fe80::226:2dff:fe20:30%2 local addr fe80::21d:72ff:feb3:a5d2%2 -> <null> 8 May 14:47:22 ntpd[28281]: fe80::21e:c9ff:fe46:dc31%2 local addr fe80::21d:72ff:feb3:a5d2%2 -> <null> 8 May 14:47:35 ntpd[28281]: Listen normally on 6 eth0 192.168.1.30:123 8 May 14:47:35 ntpd[28281]: Listen normally on 7 eth0 [fe80::21d:72ff:feb3:a5d2%2]:123 -- These are my opinions. I hate spam. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
