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