Hal Murray <hmur...@megapathdsl.net>: > > e...@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> _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
