Thread (53 messages) 53 messages, 8 authors, 2012-02-27

Re: [PATCH v10 06/11] seccomp: add SECCOMP_RET_ERRNO

From: Will Drewry <wad@chromium.org>
Date: 2012-02-21 22:48:10
Also in: lkml, netdev

On Tue, Feb 21, 2012 at 4:41 PM, Kees Cook [off-list ref] wrote:
On Tue, Feb 21, 2012 at 11:30:30AM -0600, Will Drewry wrote:
quoted
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 0043b7e..23f1844 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -136,22 +136,18 @@ static void *bpf_load(const void *nr, int off, unsigned int size, void *buf)
 static u32 seccomp_run_filters(int syscall)
 {
      struct seccomp_filter *f;
-     u32 ret = SECCOMP_RET_KILL;
      static const struct bpf_load_fn fns = {
              bpf_load,
              sizeof(struct seccomp_data),
      };
+     u32 ret = SECCOMP_RET_ALLOW;
      const void *sc_ptr = (const void *)(uintptr_t)syscall;
-
      /*
       * All filters are evaluated in order of youngest to oldest. The lowest
       * BPF return value always takes priority.
       */
-     for (f = current->seccomp.filter; f; f = f->prev) {
-             ret = bpf_run_filter(sc_ptr, f->insns, &fns);
-             if (ret != SECCOMP_RET_ALLOW)
-                     break;
-     }
+     for (f = current->seccomp.filter; f; f = f->prev)
+             ret = min_t(u32, ret, bpf_run_filter(sc_ptr, f->insns, &fns));
      return ret;
 }
I'd like to see this fail closed in the (theoretically impossible, but
why risk it) case of there being no filters at all. Could do something
like this:

       u32 ret = current->seccomp.filter ? SECCOMP_RET_ALLOW : SECCOMP_RET_KILL;

Or, just this, to catch the misbehavior:

       if (unlikely(current->seccomp.filter == NULL))
               return SECCOMP_RET_KILL;
I think the last one makes the most sense to me.  I'll add it and rev the patch.

thanks!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help