Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1225531

Re: v2 of seccomp filter c/r patches

Show all headers | View raw

On Tue, Sep 15, 2015 at 11:26 AM, Tycho Andersen
<tycho.andersen@canonical.com> wrote:
> Hi Andy,
>
> On Tue, Sep 15, 2015 at 11:13:51AM -0700, Andy Lutomirski wrote:
>> On Tue, Sep 15, 2015 at 9:07 AM, Tycho Andersen
>> <tycho.andersen@canonical.com> wrote:
>> > Hi Andy,
>> >
>> > On Mon, Sep 14, 2015 at 10:52:46AM -0700, Andy Lutomirski wrote:
>> >>
>> >> I'm not sure I entirely like this solution...
>> >
>> > Ok. Since we also aren't going to do all the eBPF stuff now, how about
>> > something that looks like this:
>> >
>> > struct seccomp_layer {
>> >   unsigned int size;
>> >   unsigned int type; /* SECCOMP_BPF_CLASSIC or SECCOMP_EBPF or ... */
>> >   bool inherited;
>> >   union {
>> >     unsigned int insn_cnt;
>> >     struct bpf_insn *insns;
>> >   };
>> > };
>> >
>> > with a ptrace command:
>> >
>> > ptrace(PTRACE_SECCOMP_DUMP_LAYER, pid, i, &layer);
>> >
>> > If we save a pointer to the current seccomp filter on fork (if there
>> > is one), then I think the inherited flag is just,
>> >
>> > inherited = is_ancestor(child->seccomp.filter, child->seccomp.inherited_filter)
>> >
>>
>> I'm lost.  What is the inherited flag for?
>
> We need some way to expose the seccomp hierarchy, specifically which
> filters are inherited, so that we can correctly restore the filter
> tree for tasks that may use TSYNC in the future. You've mentioned that
> you don't like kcmp, so this is an alternative to that.
>

My only objection to kcmp is that IMO it's a suboptimal interface and
could be better.  I have no problem with the general principle of
asking to compare two objects.

The thing I really don't have a good handle on is whether the seccomp
filter hierarchy should look more like A:

struct seccomp_filter {
    ...;
    struct seccomp_filter *prev;
};

with the seccomp_filter being the user-visible object

Or B:

struct seccomp_layer {
   ...;  /* BPF program, etc. */
}

struct seccomp_filter {
   struct seccomp_layer *layer;
   struct seccomp_filter *prev;
};  /* or equivalent */

with seccomp_layer being the user-visible object.

A is simpler to implement in a memory-efficient way, but it's less
flexible.  I haven't come up with a compelling use case for B where A
doesn't work, with the caveat that, if an fd points to a
seccomp_filter in model A, you can't attach it unless your current
state matches its "prev" state (or an ancestor thereof), which might
be a little bit awkward.

Am I making more sense now?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

v2 of seccomp filter c/r patches Tycho Andersen <tycho.andersen@canonical.com> - 2015-09-11 02:30 +0200
  [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds Tycho Andersen <tycho.andersen@canonical.com> - 2015-09-11 02:30 +0200
    Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds Daniel Borkmann <daniel@iogearbox.net> - 2015-09-11 13:50 +0200
      Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds Tycho Andersen <tycho.andersen@canonical.com> - 2015-09-11 16:30 +0200
    Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2015-09-11 14:10 +0200
      Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds Tycho Andersen <tycho.andersen@canonical.com> - 2015-09-11 16:40 +0200
    Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds Andy Lutomirski <luto@amacapital.net> - 2015-09-11 18:30 +0200
      Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds Tycho Andersen <tycho.andersen@canonical.com> - 2015-09-11 18:50 +0200
        Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds Andy Lutomirski <luto@amacapital.net> - 2015-09-14 20:00 +0200
  Re: v2 of seccomp filter c/r patches Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2015-09-11 05:00 +0200
  Re: v2 of seccomp filter c/r patches Andy Lutomirski <luto@amacapital.net> - 2015-09-11 18:40 +0200
    Re: v2 of seccomp filter c/r patches Andy Lutomirski <luto@amacapital.net> - 2015-09-11 19:10 +0200
      Re: v2 of seccomp filter c/r patches Tycho Andersen <tycho.andersen@canonical.com> - 2015-09-11 19:30 +0200
        Re: v2 of seccomp filter c/r patches Andy Lutomirski <luto@amacapital.net> - 2015-09-14 20:00 +0200
          Re: v2 of seccomp filter c/r patches Tycho Andersen <tycho.andersen@canonical.com> - 2015-09-15 18:10 +0200
            Re: v2 of seccomp filter c/r patches Andy Lutomirski <luto@amacapital.net> - 2015-09-15 20:20 +0200
              Re: v2 of seccomp filter c/r patches Tycho Andersen <tycho.andersen@canonical.com> - 2015-09-15 20:30 +0200
                Re: v2 of seccomp filter c/r patches Andy Lutomirski <luto@amacapital.net> - 2015-09-15 22:10 +0200
                Re: v2 of seccomp filter c/r patches Tycho Andersen <tycho.andersen@canonical.com> - 2015-09-15 23:40 +0200

csiph-web