Thread (21 messages) read the whole thread 21 messages, 5 authors, 2020-05-12

Re: [PATCH v5 bpf-next 2/3] bpf: implement CAP_BPF

From: Alexei Starovoitov <hidden>
Date: 2020-05-12 23:01:18
Also in: bpf, netdev

On Tue, May 12, 2020 at 10:27:33PM +0200, Daniel Borkmann wrote:
On 5/8/20 11:53 PM, Alexei Starovoitov wrote:
[...]
quoted
@@ -2880,8 +2933,6 @@ static int bpf_prog_test_run(const union bpf_attr *attr,
  	struct bpf_prog *prog;
  	int ret = -ENOTSUPP;
-	if (!capable(CAP_SYS_ADMIN))
-		return -EPERM;
Should above be under bpf_capable() as well or is the intention to really let
(fully) unpriv users run sk_filter test progs here? I would assume only progs
that have prior been loaded under bpf_capable() should suffice, so no need to
lower the bar for now, no?
Unpriv can load sk_filter and attach to a socket. Then send data through
the socket to trigger execution.
bpf_prog_test_run is doing the same prog execution without creating a socket.
What is the concern?
quoted
  	if (CHECK_ATTR(BPF_PROG_TEST_RUN))
  		return -EINVAL;
@@ -3163,7 +3214,7 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
  	info.run_time_ns = stats.nsecs;
  	info.run_cnt = stats.cnt;
-	if (!capable(CAP_SYS_ADMIN)) {
+	if (!bpf_capable()) {
Given the JIT dump this also exposes addresses when bpf_dump_raw_ok() passes.
I presume okay, but should probably be documented given CAP_SYS_ADMIN isn't
required anymore?
Exactly. dump_raw_ok() is there. I'm not even sure why this cap_sys_admin
check is there. It looks like it can be completely removed, but I didn't
want to go that far in this set.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help