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

[Christian Brauner <christian.brauner@ubuntu.com>]

On Wed, May 20, 2020 at 12:08:52PM -0700, Linus Torvalds wrote:
> On Wed, May 20, 2020 at 12:04 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > Things seccomp is NOT expected to introspect due to complexity would be
> > stuff like the bpf() syscall.
> 
> Right.
> 
> I don't dispute at all that those kinds of pointer-to-pointer things
> exist all over.
> 
> But:
> 
> > Perhaps the question is "how deeply does seccomp need to inspect?"
> > and maybe it does not get to see anything beyond just the "top level"
> > struct (i.e. struct clone_args) and all pointers within THAT become
> > opaque? That certainly simplifies the design.
> 
> Exactly. I think that's the most common situation by far. Does anybody
> really really need to care at a deep level, and why?


We mostly don't and making all second-level pointers opaque is ok imho.
First, I don't think we need to really nest structs. (We have netlink
for that.)
Second, features for such syscall that require other pointers can and
usually will be placed under a flag in the first-level struct. If that's
filterable you have the option to turn that of based on the flag. As
long as the flag identifies one feature and not one feature that can
have other features it's no different from filtering a simple flag
anyway. Even for clone3() it only has one feature that has a pointer in
the struct and that's for checkpoint/restore and lets them select a
specific pid and it comes with a size argument that is capped by the
maximum nesting depth of pid namespaces in the kernel. So if you see
that the size argument is not 0 in the first level struct you can
disallow that too same as if it were placed under the flag. So no
second-level nesting required. Probably the first level pointer is
alreay making some people vomit but it's useful and for some syscalls
almost cannot be avoided.

But I think that we need some documented consensus on all that stuff
which I stressed in other mails before. I'll hand something in about
this, if that's ok than we can hash this out.

Christian

_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss