I'm giving up on seccomp

[Hal Murray]

esr at thyrsus.com said:
> 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. 

"too much work" in an interesting phrase.  How does that compare with "not an 
efficient use of our resources"?

I didn't mean to suggest that we should drop it totally, just that I was 
giving up on tightening things down such that we only allowed the syscalls 
needed by a particular distro/version/hardware/???

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

I think you have jumped to an unreasonable conclusion by assuming that Go 
makes seccomp unintestering.  Are you going to rewrite OpenSSL in Go?  Even 
without that, are you sure there are no bugs in Go?

Maybe we should think harder about splitting NTS-KE out from ntpd.  (Without 
NTS-KE, ntpd doesn't need libssl.  It would still need libcrypto.)

--------

My comment about early-droproot wasn't clear.  There will be a few more 
syscalls needed by the code between early and normal droproot.  Since we 
aren't processing packets during initialization there is low risk of bad guys 
getting in.  But if they do get in post-initialization, they have a few more 
syscalls they can use.


-- 
These are my opinions.  I hate spam.