> On Aug 17, 2019, at 8:02 AM, Alexei Starovoitov
> <alexei.starovoi...@gmail.com> wrote:
>
> Can any of the mechanisms 1/2/3 address the concern in mds.rst?
>
seccomp() can. It’s straightforward to use seccomp to disable bpf() outright
for a process tree. In this regard, bpf() isn’t particularly unique — it’s a
system call that exposes some attack surface and that isn’t required by most
programs for basic functionality.
At LPC this year, there will be a discussion about seccomp improvements that
will, among other things, offer fiber-grained control. It’s quite likely, for
example, that seccomp will soon be able to enable and disable specific map
types or attach types. The exact mechanism isn’t decided yet, but I think
everyone expects that this is mostly a design problem, not an implementation
problem.
This is off topic for the current thread, but it could be useful to allow bpf
programs to be loaded from files directly (i.e. pass an fd to a file into bpf()
to load the program), which would enable LSMs to check that the file is
appropriately labeled. This would dramatically raise the bar for exploitation
of verifier bugs or speculation attacks, since anyone trying to exploit it
would need to get the bpf payload through LSM policy first.
> 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.
>
Not by much. BPF maps are already largely exposed to unprivileged code (when
unprivileged_bpf_disabled=0). The attack surface is there, and they’re
arguably even more exposed than they should be. My patch 1 earlier was about
locking these interfaces down.
Similarly, my suggestions about reworking cgroup attach and program load don’t
actually allow fully unprivileged users to run arbitrary bpf() programs [0] —
under my proposal, to attach a bpf cgroup program, you need a delegated cgroup.
The mechanism could be extended by a requirement that a privileged cgroup
manager explicitly enable certain attach types for a delegated subtree.
A cgroup knob to turn unprivileged bpf on and off for tasks in the cgroup might
actually be quite useful.
[0] on some thought, the test run mechanism should probably remain root-only.
