LWN: Comments on "Yet another new approach to seccomp"

Yet another new approach to seccomp

jamesmorris — Tue, 24 Jul 2012 06:51:31 +0000

All great ideas seem "obvious" after the fact.

It's an inspired work of engineering.

architecture independent seccomp policies

pcmoore — Tue, 17 Jul 2012 18:34:22 +0000

See libseccomp -> https://lwn.net/Articles/494252

architecture independent seccomp policies

whacker — Fri, 01 Jun 2012 16:57:03 +0000

How does this stop implementing syscalls in their own code?

Yet another new approach to seccomp

Cyberax — Sun, 15 Jan 2012 22:17:53 +0000

/me runs away screaming

Yet another new approach to seccomp

liljencrantz — Sun, 15 Jan 2012 10:20:11 +0000

You mean like Lunatik, the Lua interpreter embedded in the NetBSD kernel?

Yet another new approach to seccomp

ebiederm — Fri, 13 Jan 2012 01:32:07 +0000

BPF is nice because it is trivial to verify and does not allow backwards branches.

It seems an obvious choice of scripting engine for filtering to me.

Yet another new approach to seccomp

Cyberax — Thu, 12 Jan 2012 17:44:58 +0000

That's quite a bit of lateral thinking!

So, when are we going to see kernel-mode JavaScript interpreter? :)

architecture independent seccomp policies

scottt — Thu, 12 Jan 2012 04:03:48 +0000

It seems clear that a small library that knows the syscall calling convention would be highly desirable to go along with this so that security policies can be expressed in an architecture independent way.