Is it time to drop seccomp?

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> 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.

sycomp = seccomp?

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

I don't.  How many system calls is crypto going to use, though? Isn't it all
integer arithmetic and file I/O?

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

Right, I was aware of this.

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

The ptrace mechanism that strace uses could be used to log system
calls.  That's only the easy part, though.  The hard part is
systematically exercising all paths.  My experience with the failure
of TESTFRAME suggests that for ntpd this is probably impractical.

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

See "impractical", above.


I had a long think about this over a cup of cocoa.  Our present strategy is,
in effect, to crowdsource finding function calls to be whitelisted to our
users.  I tried to think of a better strategy...

Disable seccomp? No, and not just because it's bad optics.  It would trade
noisy bugs that can be fixed for silent ones that might not be detected until
after a security breach.

Try to traverse all the execution paths ourselves? Not practical, the
state space is too large.  I could babysit runs for 50 years and it would
be like trying to empty Lake Superior with a teaspoon.

I did think of one approach that wourld work. Compile a statically-linkeed
binary and run a tool on it that enumerates all trap instructions in the
binary.

Until we can do that, I don't think we have a better option than what
we're doing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.