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

On Fri, May 22, 2020 at 02:06:06PM +1000, Aleksa Sarai wrote:
> On 2020-05-20, Kees Cook <[email protected]> wrote:
> > On Wed, May 20, 2020 at 10:24:01PM +0200, Christian Brauner wrote:
> > > On Wed, May 20, 2020 at 12:08:52PM -0700, Linus Torvalds wrote:
> > > > On Wed, May 20, 2020 at 12:04 PM Kees Cook <[email protected]> wrote:
> > > > > 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.
> > 
> > That'll make things MUCH easier. :)
> 
> To be clear, my insistence on the second-level pointers topic is coming
> from the view that we should make sure whatever model we use for the
> first iteration of deep argument inspection can be expanded to
> second-level pointers if we need them. The jump-table proposal I had was
> just an example of how we could plan out a design that could be
> implemented piece-meal (heck, we don't even need jump-tables in the
> first iteration -- so long as we have an idea for how they'd work).
> 
> I also hasten to point out that if we make all second-level pointers
> opaque then you won't be able to filter clone3() based on ->set_tid.

That's not an interesting second-level case. Either turn it on or off;
base it on set_tid_size which tells you whether someone requested it or
not. There's absolutely no reason to filter around in set_tid size ([1]).
That was considered when adding this for checkpoint restore. You either
allow someone that is sufficiently capable in the owning user namespace
of each pid namespace it wants to select specific pids in or you simply
deny it. That's not a great strawman.

Interesting second level pointers are where you have second level
pointers that can point to differnet things or multiple features at once
based on an opaque switch. If you're looking for interesting second
level pointers look at bpf(). One example, is just the
BPF_OBJ_GET_INFO_BY_FD command wich passes a struct info which contains
an fd and depending on what type of fd that is, info can be either
struct bpf_prog_info, struct bpf_map_info, or struct bpf_btf_info some
of which can have other third level pointers in there.

[1]: There already wouldn't be any point to this if it were a first
     level pointer because you always need to determine the pid
     namespace hierarchy of the caller first to know whether or not you
     want to deny choosing a specific pid in a given namespace. That's
     nonsense.

> Now, maybe that's something nobody cares about, but it should be taken
> into consideration that one of the handful of "obvious" syscalls will
> already not be completely-filterable with second-level pointers being
> opaque.
> 
> But if that's fine (at least for a first iteration), then I'm also okay
> with that.
> 
> > > 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.
> > 
> > Aleksa, I know you had an entire presentation[1] on the extensible
> > argument syscalls, but was there any text-based design doc that you made?
> > 
> > It would be really nice to update Documentation/process/adding-syscalls.rst
> > with the specifics[2], and to (now) include the "no nested flags"
> > requirement. What do you think?
> 
> Christian and I wrote a patch for adding-syscalls last year[1], but Jon
> felt that it should require greater community consensus before it gets
> put into adding-syscalls. But yes, I'm definitely in favour of having
> this be a properly-documented aspect of new syscall design.
> 
> [1]: https://lore.kernel.org/linux-doc/[email protected]/
> 
> -- 
> Aleksa Sarai
> Senior Software Engineer (Containers)
> SUSE Linux GmbH
> <https://www.cyphar.com/>


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