[PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf

[Thomas Gleixner]

Alexei,

On Sat, 17 Aug 2019, Alexei Starovoitov wrote:
> On Fri, Aug 16, 2019 at 10:28:29PM +0200, Thomas Gleixner wrote:
> > On Fri, 16 Aug 2019, Alexei Starovoitov wrote:
> > While real usecases are helpful to understand a design decision, the design
> > needs to be usecase independent.
> > 
> > The kernel provides mechanisms, not policies. My impression of this whole
> > discussion is that it is policy driven. That's the wrong approach.
> 
> not sure what you mean by 'policy driven'.
> Proposed CAP_BPF is a policy?

I was referring to the discussion as a whole.
 
> Can kernel.unprivileged_bpf_disabled=1 be used now?
> Yes, but it will weaken overall system security because things that
> use unpriv to load bpf and CAP_NET_ADMIN to attach bpf would need
> to move to stronger CAP_SYS_ADMIN.
> 
> With CAP_BPF both load and attach would happen under CAP_BPF
> instead of CAP_SYS_ADMIN.

I'm not arguing against that.

> > So let's look at the mechanisms which we have at hand:
> > 
> >  1) Capabilities
> >  
> >  2) SUID and dropping priviledges
> > 
> >  3) Seccomp and LSM
> > 
> > Now the real interesting questions are:
> > 
> >  A) What kind of restrictions does BPF allow? Is it a binary on/off or is
> >     there a more finegrained control of BPF functionality?
> > 
> >     TBH, I can't tell.
> > 
> >  B) Depending on the answer to #A what is the control possibility for
> >     #1/#2/#3 ?
> 
> Can any of the mechanisms 1/2/3 address the concern in mds.rst?

Well, that depends. As with any other security policy which is implemented
via these mechanisms, the policy can be strict enough to prevent it by not
allowing certain operations. The more fine-grained the control is, it
allows the administrator who implements the policy to remove the
'dangerous' parts from an untrusted user.

So really question #A is important for this. Is BPF just providing a binary
ON/OFF knob or does it allow to disable/enable certain aspects of BPF
functionality in a more fine grained way? If the latter, then it might be
possible to control functionality which might be abused for exploits of
some sorts (including MDS) in a way which allows other parts of BBF to be
exposed to less priviledged contexts.

> I believe Andy wants to expand the attack surface when
> kernel.unprivileged_bpf_disabled=0
> Before that happens I'd like the community to work on addressing the text above.

Well, that text above can be removed when the BPF wizards are entirely sure
that BPF cannot be abused to exploit stuff. 

Thanks,

	tglx