[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 22 May 2016 23:30:34 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: Daniel Borkmann <daniel@...earbox.net>, Kees Cook <keescook@...omium.org>
Cc: linux-security-module <linux-security-module@...r.kernel.org>,
Andreas Gruenbacher <agruenba@...hat.com>, Andy Lutomirski
<luto@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Casey Schaufler <casey@...aufler-ca.com>,
David Drysdale <drysdale@...gle.com>, Eric Paris <eparis@...hat.com>,
James Morris <jmorris@...ei.org>, Jeff Dike <jdike@...toit.com>,
Julien Tinnes <jln@...gle.com>, Michael Kerrisk <mtk.manpages@...il.com>,
Paul Moore <pmoore@...hat.com>, Richard Weinberger <richard@....at>,
"Serge E . Hallyn" <serge@...lyn.com>, Stephen Smalley <sds@...ho.nsa.gov>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Will Drewry <wad@...omium.org>, Linux API <linux-api@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
alexei.starovoitov@...il.com
Subject: Re: [RFC v1 00/17] seccomp-object: From attack surface reduction to
sandboxing
Hi Daniel,
On 21/05/2016 17:19, Daniel Borkmann wrote:
> Out of curiosity, did you have a look whether adding some very basic
> eBPF support for seccomp-BPF could also enable you for the option of
> inspecting arguments eventually?
>
> With basic, I mean adding new eBPF program type BPF_PROG_TYPE_SECCOMP
> and the only things allowed would be to use a very limited set of
> helpers. No maps, etc allowed for this type. If needed for extracting
> args, you could extend struct seccomp_data for eBPF use, and add new
> set of helper functions that would allow you to extract/walk arguments,
> and, for example, pass the extracted buffer back to the eBPF prog for
> further inspection.
>
> Have a look at samples in [1,2], which are for tracing though, but possibly
> it could be designed in a more or less similar way, where clang compiles
> this policy down into eBPF bytecode. Did you have a look at this direction
> or any thoughts on it?
>
> [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/samples/bpf/tracex5_kern.c
> [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/samples/bpf/tracex1_kern.c
One of my initial goals was to use as much as possible the existing code without modifying the BPF part. I use (or abuse) the seccomp BPF stack to be able to run some checks by the kernel outside the BPF but get the result from each intermediate BPF.
I have not really looked at the eBPF possibilities, but that seems interesting now that I plan to move the kernel object evaluation part only in the LSM. However, the current seccomp code is whitelisting a very small subset of BPF and it would extend the attack surface to add some more commands. But maybe, as you said, we could create some custom eBPF functions dedicated to kernel object inspection and add them (BPF_CALL) to the current whitelist (for the LSM). It would be less hacky than the stacked BPF I used, but could be more complex.
Kees, what do your think about this?
Download attachment "signature.asc" of type "application/pgp-signature" (456 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
