Should we dump seccomp?

[Eric S. Raymond]

Hal Murray via devel <devel at ntpsec.org>:
> 
> 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.

Yes, it's pretty straighword to run an strace.

For that reason I'm inclined to say we should deal with the irritation of having
to update our whitelist on occasion.

Especially since...well, we're supposed to be about security. It would be
a bit perverse to drop a security feature just because it's occasionally
inconvenient.

> 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.

The way I wanted to fix this was by going to a simpler socket-IO design in
which everything is dome through wildcard interfaces.  That plan got shot
down by the requirement to support per-interface filtering rules.

> In case it isn't obvious, I think this is pretty far down in the weeds. 

Agreed.  I think it's good to bring up this kind of possibility, though.
Due diligence and all that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.