I'm giving up on seccomp

Hal Murray hmurray at megapathdsl.net
Wed Sep 2 03:27:25 UTC 2020


[This has been in the works for a while, but I keep forgetting to type it in.]

Seccomp is a rathole.  I'm tired of it.  I think my time will be better spent 
on other things and/or our time could be better spent on other approaches - 
jails and such.  What's the word for what Debian does?

------------

This is a dump of what I know and/or have done recently.

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?

If a serious bad guy finds a 0-day in ntpd, they can get the list of allowed 
syscalls from our source code and tweak their code to dance around anything we 
would trap.

Our current list of allowed syscalls is the collection of everything that any 
OS/distro/version has ever needed, rounded down if the compiler can figure out 
that a call doesn't exist.  That lets you check the we-support-seccomp box.  
Things are slightly complicated by early-droproot  -- it needs a few syscalls 
that are only used during initialization.  [Is early-droproot a bug?]

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

Part of the idea was that we could ship of bunch of files known to work for various distros/versions/hardware/...  The list gets pretty large.  Tracking changes in libc and libssl would be a pain.

------------

We use seccomp with a simple list of allowed syscalls.  I think there is an option to filter on arguments.  That might be interesting, for example, to restrict where we can open files for writing.

------------

If you are paranoid, you could setup a server without DNS or NTS.  That doesn't seem very interesting for public servers but might be interesting in a restricted environment.  You could get authentication using shared keys.

It might be possible to split out the NTS-KE server to another process so the server side of ntpd could handle NTP+NTS packets without libssl.  With a bit more work, the NTS-KE server could be on another system.


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list