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

[Andy Lutomirski <luto@kernel.org>]

On Thu, Aug 15, 2019 at 10:48 AM Kees Cook <keescook@chromium.org> wrote:
>
> 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...
>

But also clone() flag filtering, and new clone() proposals keep
wanting to add structs.  And filtering bpf().  /me runs.

But yes, doing this LSM-style could also make sense.