Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Alexei Starovoitov <hidden>
Date: 2019-08-16 21:45:56
Also in:
bpf, linux-api, netdev
On Thu, Aug 15, 2019 at 05:54:59PM -0700, Andy Lutomirski wrote:
quoted
On Aug 15, 2019, at 4:46 PM, Alexei Starovoitov [off-list ref] wrote:quoted
quoted
I'm not sure why you draw the line for VMs -- they're just as buggy as anything else. Regardless, I reject this line of thinking: yes, all software is buggy, but that isn't a reason to give up.hmm. are you saying you want kernel community to work towards making containers (namespaces) being able to run arbitrary code downloaded from the internet?Yes. As an example, Sandstorm uses a combination of namespaces (user, network, mount, ipc) and a moderately permissive seccomp policy to run arbitrary code. Not just little snippets, either — node.js, Mongo, MySQL, Meteor, and other fairly heavyweight stacks can all run under Sandstorm, with the whole stack (database engine binaries, etc) supplied by entirely untrusted customers. During the time Sandstorm was under active development, I can recall *one* bug that would have allowed a sandbox escape. That’s a pretty good track record. (Also, Meltdown and Spectre, sigh.)
exactly: "meltdown", "spectre", "sigh". Side channels effectively stalled the work on secure containers. And killed projects like sandstorm. Why work on improving kaslr when there are several ways to get kernel addresses through hw bugs? Patch mouse holes when roof is leaking ? In case of unprivileged bpf I'm confident that all known holes are patched. Until disclosures stop happening with the frequency they do now the time of bpf developers is better spent on something other than unprivileged bpf.
I’m suggesting that you engage the security community ... .. so that normal users can use bpf filtering
yes, but not soon. unfortunately.