I'm looking at strace output. There are a few calls used only once or twice.
It seems obvious that we should drop root as early as possible. But it's not obvious that we should enable seccomp early. If we turn on seccomp early, then we have to allow all the syscalls used during initialization so a bad guy could use them too. So what are we worried about? What is seccomp trying to protect against? Bugs in our initialization code before we start exchanging packets, or bugs in the mainline code after initialization when the bad guys get to send us packets? If the latter, we can reduce the allowed syscalls by deferring turning on seccomp until we have finished initialization. Can anybody think of a case where early droproot doesn't work? Any reason I shouldn't split droproot and seccomp so we can do early droproot with late syscomp? Can we do the droproot even earlier? Another option would be to do an early seccomp that still allowed secomp so we could do another seccomp to turn off the initialization syscalls. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
