Seccomp tangle

[Hal Murray]

esr at thyrsus.com said:
>> If yes, I'll need some help to work out the details.
> Aaarrgghhh.  It;s a huge pain in the ass and I wish it weren't interesting.
> But given our mission statememnnt, it has to be. 

OK.  Let's discuss how to do it.

I was thinking of putting the individual lists in ntpd/seccomp/
with something like
  #include "seccomp/foo.c"
in ntp_sandbox.

The first quirk is that ntpd isn't on the #include search path.
(My hack was to put a link from include to ntpd/seccomp)
What's the right way to handle this?  (Maybe I just fatfingered things.)

The second quirk is that we can't put the filename from --enable-seccomp=foo 
into config.h and use cpp to adjust what gets included.  (Well, we could with 
another preliminary pass.)  My hack was to #include "seccomp/default.c" and 
make default a link to the file I want.  (Needs a better name.)

After that, it's mostly a lot of work to collect the data for the systems you 
are interested in.

Note that --enable-early-droproot might use a few more syscalls and moving 
init code to before the normal droproot might remove a few syscalls from the 
list of the ones we need.

Where should the scripts and directions live?

We also need to collect a list of corner cases that don't happen often and how 
to trigger them so that the strace info captures the data we need.  The simple 
example is stepping the clock for a big adjustment.  We can trigger that by 
bumping the clock far enough with ntpfrob -b and waiting for ntpd to notice 
and step it back.

-- 
These are my opinions.  I hate spam.