Hal Murray via devel writes: > It seems obvious that we should drop root as early as possible. But it's not > obvious that we should enable seccomp early.
Root should be dropped before ntpsec starts accepting network input. Dropping it even earlier doesn't buy you much, since it'd only reduce the window of opportunity against an attacker that can already control the local system. But droproot and seccomp are really orthogonal in that they target different aspects of exploitability. > 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. As already mentioned, you could restrict the list of calls as you go. That is, if you can enumerate them and know when they are used (and when not), which precisely is the problem of seccomp. I posit that seccomp is not really intended to secure system level daemons, it's intended use is really to ensure that numerical simulation codes don't do anything stupid when they crash. So you give these a pipe to read from, a pipe to write to and then restrict any other system system calls so when they hit the inevitable bug or data error the only bad thing that happens is the process gets killed. > 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? Seccomp protects against the use of arbitrary syscalls, i.e. someone has already breached ntpd in some way and built a sled/trampoline that can launch system calls. Seccomp then merely makes it more difficult for the attacker to use that facility. > 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? Does ntpd need root for anything other than opening files/interfaces? > 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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
