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?