Re: [Ksummit-discuss] [TECH TOPIC] seccomp

[Kees Cook <keescook@chromium.org>]

On Wed, Aug 14, 2019 at 10:54:49AM -0700, Andy Lutomirski wrote:
> After thinking about this a bit more, I think that deferring the main
> seccomp filter invocation until arguments have been read is too
> problematic.  It has the ordering issues you're thinking of, but it
> also has unpleasant effects if one of the reads faults or if
> SECCOMP_RET_TRACE or SECCOMP_RET_TRAP is used.  I'm thinking that this

Right, I was actually thinking of the trace/trap as being the race.

> type of deeper inspection filter should just be a totally separate
> layer.  Once the main seccomp logic decides that a filterable syscall
> will be issued then, assuming that no -EFAULT happens, a totally
> different program should get run with access to arguments.  And there
> should be a way for the main program to know that the syscall nr in
> question is filterable on the running kernel.

Right -- this is how I designed the original prototype: it was
effectively an LSM that was triggered by seccomp (since LSMs don't know
anything about syscalls -- their hooks are more generalized). So seccomp
would set a flag to make the LSM hook pay attention.

Existing LSMs are system-owner defined, so really something like Landlock
is needed for a process-owned LSM to be defined. But I worry that LSM
hooks are still too "deep" in the kernel to have a process-oriented
filter author who is not a kernel developer make any sense of the
hooks. They're certainly oriented in a better position to gain the
intent of a filter. For example, if a filter says "you can't open(2)
/etc/foo", but it misses saying "you can't openat(2) /etc/foo", that's a
dumb exposure. The LSM hooks are positioned to say "you can't manipulate
/etc/foo through any means".

So, I'm not entirely sure. It needs a clear design that chooses and
justifies the appropriate "depth" of filtering. And FWIW, the two most
frequent examples of argument parsing requests have been path-based
checking and network address checking. So any prototype needs to handle
these two cases sanely...

-- 
Kees Cook