I'm giving up on seccomp

[Eric S. Raymond]

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

Sometimes you have make efforts in the direction of being seen to do the right
thing that can't be considered strictly efficient.  Support for the BSD Unixes
is in this category, too.

> 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/???

Oh.  I'm fine with that path.  I thought you wanted to heave seccomp
overboard in its entirety.

> I think you have jumped to an unreasonable conclusion by assuming that Go 
> makes seccomp unintestering.  Are you going to rewrite OpenSSL in Go?

No.  There's an opennsl binding: https://godoc.org/github.com/spacemonkeygo/openssl

> Even without that, are you sure there are no bugs in Go?

No, I'm not.  But neither do I think seccomp is actually *possible* in Go
at this point, which tends to relieve us of having to support it.

> Maybe we should think harder about splitting NTS-KE out from ntpd.

I lean against that - it seems like that split would make deploytment
and configuration more complicated.  But I could be persuaded.

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

Got it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>