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

On Wed, May 20, 2020 at 11:06 AM Kees Cook <[email protected]> wrote:
> We already have structs passed to syscalls that contain pointers to yet
> more structs.

Give real examples of where this matters for security, please, and
where somebody would want to control this.

Yes, we have things like clone3() that pass a struct with pointers to
user space (eg the wait location etc).

Yes, we have tons of things like ioctl's that have random struct
pointer arguments with random contents.

Yes, we have iovec's etc that have arrays of pointers to user space.

But no, none of these seem to be things that seccomp should care about.

So I am not in the least interested in some kind of general discussion
about system calls with "pointers to pointers". They exist. Deal with
it. It's not in the least an interesting issue, and no, we shouldn't
make seccomp and friends incredibly more complicated for it.

If you want to do sandboxing, you disallow those things entirely if
you don't trust them, or make the case-by-case argument for why they
don't matter.

If you want to do something fancier (special compat emulation using
seccomp and a ptrace fallback? I dunno) you are going to just have to
deal with it. It's not simple, but it's not the kernels problem. You
may have to emulate it *entirely* in the ptracer (ie instead of "check
the arguments and let it continue" you _actually_ emulate it to avoid
any races)

And if you have some actual and imminent real security issue, you
mention _that_ and explain _that_, and accept that maybe you need to
do that expensive emulation (because the kernel people just don't care
about your private hang-ups) or you need to explain why it's a real
issue and why the kernel should help with your odd special case.

Don't make this some kind of abstract conceptual problem thing.
Because it's not.

Some computer scientists think that everythinig should be really
generic and solutions that solve some problem for every possible case
are the only good solutions.

But those people are wrong. The thing that _really_ matters is the
details. Not the nebulous theory.

So details, please.

             Linus
_______________________________________________
Ksummit-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss