I'm giving up on seccomp

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> You keep saying seccomp is important.  What does it buy us?  ntpd is a big 
> complicated program.  It reads and writes files.  It opens network 
> connections.  What else would a bad guy need to do?

I think you misunderstand.  I don't believe seccomp is objectively
very important in itself, and never have.  My problem with dropping it
is that if we do that, we could be seen to have abandoned part of a
security defense in depth because it's too much work.  That's not a
good look for a project with our mission statememt.

On the other hand, I can't blame you a bit for being tired of this
rathole, because it is indeed a huge pain in the ass for marginal
gain. I don't think any of your analysis is even a little wrong about
that.

The solution is simple and obvious, if really annoying for me.  You
should assign seccomp-related bugs to me and I will deal with them.
Think of this as incentive for me to get serious about moving the
daemon to Go :-).

(In Go, the equivalent of seccomp is neither possible nor necessary.
What makes it unnecessary is that while you can crash a Go program
with a bad reference, you can't weird-machine it. (Actually
technically you can, but it takes a specific evasion of the language's
safety rules thriugn the unsafe module)).

> [Is early-droproot a bug?]

At the current state of my knowledge I don't think so.  But you just
put auditing the stretch of code between the two droproots high on my
priority list.  It's an open question whether early droproot is worth
its complexity cost. This is not a case like seccomp where the set of
exploits closed off is effectively unbounded - in this case the
security cost of proliferating code and test paths may not be worth
the earlier privilege drop.

> We use 2 large libraries that do lots of syscalls: libc and libssl.  Most of 
> libc is a thin wrapper over the obvious.  Sometimes it is a little less thin 
> when translating an old version into a newer syscall.
> 
> The complicated part of libc that we use is DNS lookups.  That's a pain to 
> debug.  DNS disables most signals so you can't bail out without letting it 
> cleanup.  So it crashes rather than letting our trap handler print an error 
> message.
> 
> I have work-in-progress that lets you setup a list of syscalls actually used 
> by your environment.  It does roughly the following:
>   Splits the list of syscalls to be allowed out to a separate file that gets 
> #includ-ed.
>   A handful of scripts that process strace output to make lists of needed 
> calls.
>   It needs some waf work to specify the filename.  I'm just patching a link to 
> point to the right file.
> 
> To collect the data, you have to run ntpd under strace.  While it is running, you have to tickle all the uncommon code paths.  Things like switching to a new ntpd.log after log rotate or reloading the cert file after it has been updated.  I have a list.  I don't know how complete it is.
> 
> One of the scripts includes a few syscalls that are hard to tickle.  That would need double checking.
> 
> Basically, making a file is enough of a pain that I don't think it's practical.  You have to be a semi-wizard in order to run the recipe.  A new libc or libssl may break things.
> 
> If somebody else wants to pick up this work I'll be glad to hand over what I have.  Otherwise, I'll drop it.  (It's not hard to recreate from scratch if you understand the above description.)

I'm going to say drop it, and here's why.

We've already seen the frequency of seccomp bugs drop over time, and that's
to be expected. There should be fewer in the fture than there have been
in the past, lowering the value of building those specualized tools. Me,
I'd rarher you spent your effort on devoising better test protocols
as you have been doing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>