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

On Fri, May 22, 2020 at 09:35:35AM +0200, Christian Brauner wrote:
> 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.

Other examples include (possibly epoll_ctl's struct epoll_event),
struct iovec in general, {get,set}_robust_list(), kexec_load()'s struct
kexec_segment, and sendmsg()'s and recvmsg()'s sruct msghdr with a large
number of additional substructs passed through passing a struct iovec.
Most of these I reckon are uninteresting and will just in general be not
allowed if there's a problem.

> 
> [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.
_______________________________________________
Ksummit-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss