Should we dump seccomp?

[Hal Murray]

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.