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"? 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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
