Is it time to drop seccomp?

Hal Murray hmurray at megapathdsl.net
Wed Feb 13 02:51:36 UTC 2019


esr at thyrsus.com said:
> What additional syscalls does it imply? 

I don't know.  I had syscomp enabled on my test machine.  The first time I 
tried NTS, it blew up, so I turned it off and went back to work on NTS.

My reading on syscomp is that some tools are missing.  Without them, it's not 
ready for real use.

There is enough code in libc that it isn't simple to predict what syscalls are 
actually used.  DNS lookup is a sample ugly case.  Who knows what's in TLS.

The current approach is to run it until it crashes, then add that syscall to 
the list.  That is insecure it 2 ways.  It allows some syscalls that aren't 
actually used because they were used on some other environment.  It may not 
allow syscalls used by obscure cases because nobody using seccomp has hit that 
case yet on this environment.

We need a tool that would generate the list of syscalls.  Maybe at run time, 
by trapping everything and enabling the ones that get used and writing them 
out to a file.  That would be sufficient if we had a test procedure that 
exercised all interesting paths, including lost packets.

Note that if you have the tool and the test deck, you still have to get a hook 
into the software release procedures so you can rerun the tool when any of the 
libraries you use get updated.


Are you willing to be the babysitter?  If so, turn on NTS and see what 
happens.  Here is a sample from my log file.

 7 Feb 21:43:14 ntpd[5866]: ERR: SIGSYS/seccomp bad syscall 99/0xc000003e
 7 Feb 21:43:14 ntpd[5866]: ERR: Stack trace:
 7 Feb 21:43:14 ntpd[5866]: ERR:  ./hgm/main/ntpd/ntpd(+0x19e0b) 
[0x5618bf6b6e0b]
 7 Feb 21:43:14 ntpd[5866]: ERR:  /lib64/libpthread.so.0(+0x13030) 
[0x7f2b593de030]
 7 Feb 21:43:14 ntpd[5866]: ERR:  /lib64/libc.so.6(sysinfo+0xb) 
[0x7f2b5930335b]
 7 Feb 21:43:14 ntpd[5866]: ERR:  /lib64/libc.so.6(get_phys_pages+0x23) 
[0x7f2b59300143]
...

There is a paragraph of hints in front of catchTrap in ntp_sandbox.

I'd use gdb with a breakpoint in the routine that does the stack trace.  But 
that's because I'm curious and want to see the stack rather than just fix the 
problem.


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list