> On Aug 27, 2019, at 5:55 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > On Tue, Aug 27, 2019 at 5:34 PM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: >> > From the previous discussion, you want to make progress toward solving > a lot of problems with CAP_BPF. One of them was making BPF > firewalling more generally useful. By making CAP_BPF grant the ability > to read kernel memory, you will make administrators much more nervous > to grant CAP_BPF. Similarly, and correct me if I'm wrong, most of > these capabilities are primarily or only useful for tracing, so I > don't see why users without CAP_TRACING should get them. > bpf_trace_printk(), in particular, even has "trace" in its name :) > > Also, if a task has CAP_TRACING, it's expected to be able to trace the > system -- that's the whole point. Why shouldn't it be able to use BPF > to trace the system better? Let me put this a bit differently. Part of the point is that CAP_TRACING should allow a user or program to trace without being able to corrupt the system. CAP_BPF as you’ve proposed it *can* likely crash the system. For example, CAP_BPF allows bpf_map_get_fd_by_id() in your patch. If the system uses a BPF firewall that stores some of its rules in maps, then bpf_map_get_fd_by_id() can be used to get a writable fd to the map, which can be used to change the map, thus preventing network access. This means that no combination of CAP_TRACING and CAP_BPF ends up allowing tracing without granting the ability to reconfigure or otherwise corrupt the system.
