droproot, seccomp

Hal Murray hmurray at megapathdsl.net
Tue Feb 25 05:02:41 UTC 2020


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.





More information about the devel mailing list