On 02/28/2018 02:56 PM, Daniel Borkmann wrote:

On 02/28/2018 12:55 AM, chris hyser wrote:

quoted

If you're implying that because seccomp would have it's own verifier and could therefore restrict itself to a subset of eBPF, 
therefore any future additions/features to eBPF would not necessarily make seccomp less secure, I mainly agree. Is that th
argument?

Ok, in addition to the current unpriv restrictions imposed by the verifier,
what additional requirements would you have from your side in order to get
to semantics that make sense for you wrt seccomp/eBPF? Just trying to
understand how far we are away from that. Note that not every new feature,
map or helper is enabled for every program type of course.

Let me try to clarify my argument by laying out my thoughts here (I apologize if it seems pedantic):

The intent of seccomp is to reduce the kernel attack surfaces available to a compromised user program; if you can't make 
a syscall, you can't exploit some lurking security bug.

Now, if I order various possible seccomp implementation choices in terms of minimizing that implementation's kernel 
attack surfaces it might reasonably be:

1) simple bit vector go/no go check (or similar)
2) cBPF like today
3) some restricted subset of eBPF
4) some other or less restricted subset of eBPF
5) all current eBPF
6) eBPF plus future features

The trade-off is that more features equals less security (ie more security risk). The question is do we allow user land 
to decide where they want to be on that scale or do we pick knowing it will be too much for some and too little for 
others. Answering your question therefore requires knowing either where we choose to be on that scale or what options 
and at what granularity we allow user land to choose. In terms of user land options, just choosing between 2 and 5 might 
be enough. I'd favor say 1 and 4 or 1 and 5 as I don't think it unreasonable for the security paranoid to choose 1.

-chrish