Should we dump seccomp?

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> Eric said:
> > 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.
> 
> How many of you are using it?
> 
> Should we change the default to be --enable-seccomp?  (If on Linux)

I didn't know it wasn't already defaulted to on.  Was it in the Classic build?

> If we are serious about supporting it, we need a way to get a stack track 
> from the signal handler.  Eric: Please add that to your list.

I thnk that code is already in place.  But I don't think I've ever seen it
triggered, so I don't know if it actually works. Take a look at backtrace.c
in the ISC library and its callsites.

> Should we just keep adding syscalls, or should we try to figure out which 
> ones are needed by each distro/version?  It probably depends on the libc 
> version, but I don't know how often there are significant local mods.

I believe significant local mods must be rare - I don't know of any.  Keep
adding syscalls is probably the right thing because we don't need the
complexity burden of fine-grain tracking per-distro dependencies.

> Should we work on a no-DNS version?  It's no good for the typical client/pool 
> case, but it might be interesting for a server.

I'm against this idea. I think it would add test complexity without
a commensrate gain.

> > Yes, it's pretty straighword to run an strace.
> 
> Unless it only happens when ntpd is starting during booting.

Good point.

> We had a dangling case for a while until somebody mentioned strace and I 
> hacked my startup script to use strace.  I should have documented the recipe.

Good thing to add to devek/testing.txt?
-- 
		<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.