capable_bpf_net_admin()

capable_bpf_net_admin()

[Maciej Żenczykowski]

is
(SYS_ADMIN || BPF) && NET_ADMIN

should this not be
SYS_ADMIN || (BPF && NET_ADMIN)

?

Won't this cause a just SYS_ADMIN process to fail to load network bpf progs?

(I haven't debugged this at all, but John is reporting 5.8-rc1 fails
to load bpf progs from Android's bpfloader with EPERM error)

Or are we okay with this user space visible behavioural change?

Re: capable_bpf_net_admin()

[Alexei Starovoitov]

On Wed, Jun 17, 2020 at 11:43 PM Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
>
> is
> (SYS_ADMIN || BPF) && NET_ADMIN
>
> should this not be
> SYS_ADMIN || (BPF && NET_ADMIN)
>
> ?

capable_bpf_net_admin doesn't exist.

> Won't this cause a just SYS_ADMIN process to fail to load network bpf progs?

if the process has cap_sys_admin it has all privs.

> (I haven't debugged this at all, but John is reporting 5.8-rc1 fails
> to load bpf progs from Android's bpfloader with EPERM error)
>
> Or are we okay with this user space visible behavioural change?

What kind of change? Could you please be more specific?

Re: capable_bpf_net_admin()

[Maciej Żenczykowski]

John has all the details.  I'm just guessing.

But having actually looked at the code, commit 2c78ee898d8f1 ie.

kernel/bpf/syscall.c: bpf_prog_load()
+       if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN))
+               return -EPERM;

looks fishy, since our bpfloader only has CHOWN SYS_ADMIN, and the
maps/programs it creates/loads are used by netd which only has
NET_ADMIN (but not SYS_ADMIN).  Furthermore I don't really want to
grant it NET_ADMIN.

I think this should again be either NET_ADMIN or SYS_ADMIN.

On Thu, Jun 18, 2020 at 12:01 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Jun 17, 2020 at 11:43 PM Maciej Żenczykowski
> <zenczykowski@gmail.com> wrote:
> >
> > is
> > (SYS_ADMIN || BPF) && NET_ADMIN
> >
> > should this not be
> > SYS_ADMIN || (BPF && NET_ADMIN)
> >
> > ?
>
> capable_bpf_net_admin doesn't exist.
>
> > Won't this cause a just SYS_ADMIN process to fail to load network bpf progs?
>
> if the process has cap_sys_admin it has all privs.
>
> > (I haven't debugged this at all, but John is reporting 5.8-rc1 fails
> > to load bpf progs from Android's bpfloader with EPERM error)
> >
> > Or are we okay with this user space visible behavioural change?
>
> What kind of change? Could you please be more specific?

Re: capable_bpf_net_admin()

[John Stultz]

On Thu, Jun 18, 2020 at 3:20 AM Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
>
> John has all the details.  I'm just guessing.
>
> But having actually looked at the code, commit 2c78ee898d8f1 ie.
>
> kernel/bpf/syscall.c: bpf_prog_load()
> +       if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN))
> +               return -EPERM;
>
> looks fishy, since our bpfloader only has CHOWN SYS_ADMIN, and the
> maps/programs it creates/loads are used by netd which only has
> NET_ADMIN (but not SYS_ADMIN).  Furthermore I don't really want to
> grant it NET_ADMIN.
>
> I think this should again be either NET_ADMIN or SYS_ADMIN.

Just to confirm, reverting 2c78ee898d8f1 (which doesn't revert
perfectly cleanly) seems to avoid the failure I was seeing.

And specifically in the chunk Maciej pointed out above, if we just
switch the check to CAP_SYS_ADMIN it also avoids the problem.

Let me know if there is anything folks would like me to test!

thanks
-john

Re: capable_bpf_net_admin()

[Maciej Żenczykowski]

Ok so I think

> +       if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN))
> +               return -EPERM;

should be

> +       if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN) && !capable(CAP_SYS_ADMIN))
> +               return -EPERM;

and presumably similar change just below that for perfmon.

[PATCH] restore behaviour of CAP_SYS_ADMIN allowing the loading of net bpf program

[Maciej Żenczykowski]

From: Maciej Żenczykowski <maze@google.com>

This is a 5.8-rc1 regression.

Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF")
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
 kernel/bpf/syscall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 8da159936bab..7d946435587d 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -2121,7 +2121,7 @@ static int bpf_prog_load(union bpf_attr *attr, union bpf_attr __user *uattr)
 	    !bpf_capable())
 		return -EPERM;
 
-	if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN))
+	if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN) && !capable(CAP_SYS_ADMIN))
 		return -EPERM;
 	if (is_perfmon_prog_type(type) && !perfmon_capable())
 		return -EPERM;
-- 
2.27.0.290.gba653c62da-goog

Re: [PATCH] restore behaviour of CAP_SYS_ADMIN allowing the loading of net bpf program

[Alexei Starovoitov]

On Thu, Jun 18, 2020 at 1:00 PM Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
>
> From: Maciej Żenczykowski <maze@google.com>
>
> This is a 5.8-rc1 regression.

Please add full explanation here.

Also use [PATCH bpf] in the subject for future submission.

> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF")

Reported-by: John
is missing?

> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> ---
>  kernel/bpf/syscall.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 8da159936bab..7d946435587d 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -2121,7 +2121,7 @@ static int bpf_prog_load(union bpf_attr *attr, union bpf_attr __user *uattr)
>             !bpf_capable())
>                 return -EPERM;
>
> -       if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN))
> +       if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN) && !capable(CAP_SYS_ADMIN))
>                 return -EPERM;
>         if (is_perfmon_prog_type(type) && !perfmon_capable())
>                 return -EPERM;
> --
> 2.27.0.290.gba653c62da-goog
>

Re: capable_bpf_net_admin()

[John Stultz]

On Thu, Jun 18, 2020 at 12:22 PM Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
>
> Ok so I think
>
> > +       if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN))
> > +               return -EPERM;
>
> should be
>
> > +       if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN) && !capable(CAP_SYS_ADMIN))
> > +               return -EPERM;
>
> and presumably similar change just below that for perfmon.

Looks ok to me. Do you want to send out such a patch? If not I'll do
so on Monday.

thanks
-john

[PATCH bpf v2] restore behaviour of CAP_SYS_ADMIN allowing the loading of networking bpf programs

[Maciej Żenczykowski]

From: Maciej Żenczykowski <maze@google.com>

This is a fix for a regression introduced in 5.8-rc1 by:
  commit 2c78ee898d8f10ae6fb2fa23a3fbaec96b1b7366
  'bpf: Implement CAP_BPF'

Before the above commit it was possible to load network bpf programs
with just the CAP_SYS_ADMIN privilege.

The Android bpfloader happens to run in such a configuration (it has
SYS_ADMIN but not NET_ADMIN) and creates maps and loads bpf programs
for later use by Android's netd (which has NET_ADMIN but not SYS_ADMIN).

Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Reported-by: John Stultz <john.stultz@linaro.org>
Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF")
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
 kernel/bpf/syscall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 8da159936bab..7d946435587d 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -2121,7 +2121,7 @@ static int bpf_prog_load(union bpf_attr *attr, union bpf_attr __user *uattr)
 	    !bpf_capable())
 		return -EPERM;
 
-	if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN))
+	if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN) && !capable(CAP_SYS_ADMIN))
 		return -EPERM;
 	if (is_perfmon_prog_type(type) && !perfmon_capable())
 		return -EPERM;
-- 
2.27.0.111.gc72c7da667-goog

Re: [PATCH bpf v2] restore behaviour of CAP_SYS_ADMIN allowing the loading of networking bpf programs

[John Stultz]

On Sat, Jun 20, 2020 at 2:26 PM Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
>
> From: Maciej Żenczykowski <maze@google.com>
>
> This is a fix for a regression introduced in 5.8-rc1 by:
>   commit 2c78ee898d8f10ae6fb2fa23a3fbaec96b1b7366
>   'bpf: Implement CAP_BPF'
>
> Before the above commit it was possible to load network bpf programs
> with just the CAP_SYS_ADMIN privilege.
>
> The Android bpfloader happens to run in such a configuration (it has
> SYS_ADMIN but not NET_ADMIN) and creates maps and loads bpf programs
> for later use by Android's netd (which has NET_ADMIN but not SYS_ADMIN).
>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Reported-by: John Stultz <john.stultz@linaro.org>
> Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF")
> Signed-off-by: Maciej Żenczykowski <maze@google.com>

Thanks so much for helping narrow this regression down and submitting this fix!
It's much appreciated!

Tested-by: John Stultz <john.stultz@linaro.org>

thanks
-john

Re: [PATCH bpf v2] restore behaviour of CAP_SYS_ADMIN allowing the loading of networking bpf programs

[Alexei Starovoitov]

On Mon, Jun 22, 2020 at 12:44 PM John Stultz <john.stultz@linaro.org> wrote:
>
> On Sat, Jun 20, 2020 at 2:26 PM Maciej Żenczykowski
> <zenczykowski@gmail.com> wrote:
> >
> > From: Maciej Żenczykowski <maze@google.com>
> >
> > This is a fix for a regression introduced in 5.8-rc1 by:
> >   commit 2c78ee898d8f10ae6fb2fa23a3fbaec96b1b7366
> >   'bpf: Implement CAP_BPF'
> >
> > Before the above commit it was possible to load network bpf programs
> > with just the CAP_SYS_ADMIN privilege.
> >
> > The Android bpfloader happens to run in such a configuration (it has
> > SYS_ADMIN but not NET_ADMIN) and creates maps and loads bpf programs
> > for later use by Android's netd (which has NET_ADMIN but not SYS_ADMIN).
> >
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Reported-by: John Stultz <john.stultz@linaro.org>
> > Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF")
> > Signed-off-by: Maciej Żenczykowski <maze@google.com>
>
> Thanks so much for helping narrow this regression down and submitting this fix!
> It's much appreciated!
>
> Tested-by: John Stultz <john.stultz@linaro.org>

Applied to bpf tree. Thanks

Re: [PATCH bpf v2] restore behaviour of CAP_SYS_ADMIN allowing the loading of networking bpf programs

[John Stultz]

On Tue, Jun 23, 2020 at 5:54 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Mon, Jun 22, 2020 at 12:44 PM John Stultz <john.stultz@linaro.org> wrote:
> > On Sat, Jun 20, 2020 at 2:26 PM Maciej Żenczykowski
> > <zenczykowski@gmail.com> wrote:
> > > From: Maciej Żenczykowski <maze@google.com>
> > >
> > > This is a fix for a regression introduced in 5.8-rc1 by:
> > >   commit 2c78ee898d8f10ae6fb2fa23a3fbaec96b1b7366
> > >   'bpf: Implement CAP_BPF'
> > >
> > > Before the above commit it was possible to load network bpf programs
> > > with just the CAP_SYS_ADMIN privilege.
> > >
> > > The Android bpfloader happens to run in such a configuration (it has
> > > SYS_ADMIN but not NET_ADMIN) and creates maps and loads bpf programs
> > > for later use by Android's netd (which has NET_ADMIN but not SYS_ADMIN).
> > >
> > > Cc: Alexei Starovoitov <ast@kernel.org>
> > > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > > Reported-by: John Stultz <john.stultz@linaro.org>
> > > Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF")
> > > Signed-off-by: Maciej Żenczykowski <maze@google.com>
> >
> > Thanks so much for helping narrow this regression down and submitting this fix!
> > It's much appreciated!
> >
> > Tested-by: John Stultz <john.stultz@linaro.org>
>
> Applied to bpf tree. Thanks

Hey all,
  Just wanted to follow up on this as I've not seen the regression fix
land in 5.8-rc4 yet? Is it still pending, or did it fall through a
gap?

thanks
-john

Re: [PATCH bpf v2] restore behaviour of CAP_SYS_ADMIN allowing the loading of networking bpf programs

[Daniel Borkmann]

On 7/6/20 10:11 PM, John Stultz wrote:
> On Tue, Jun 23, 2020 at 5:54 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>> On Mon, Jun 22, 2020 at 12:44 PM John Stultz <john.stultz@linaro.org> wrote:
>>> On Sat, Jun 20, 2020 at 2:26 PM Maciej Żenczykowski
>>> <zenczykowski@gmail.com> wrote:
>>>> From: Maciej Żenczykowski <maze@google.com>
>>>>
>>>> This is a fix for a regression introduced in 5.8-rc1 by:
>>>>    commit 2c78ee898d8f10ae6fb2fa23a3fbaec96b1b7366
>>>>    'bpf: Implement CAP_BPF'
>>>>
>>>> Before the above commit it was possible to load network bpf programs
>>>> with just the CAP_SYS_ADMIN privilege.
>>>>
>>>> The Android bpfloader happens to run in such a configuration (it has
>>>> SYS_ADMIN but not NET_ADMIN) and creates maps and loads bpf programs
>>>> for later use by Android's netd (which has NET_ADMIN but not SYS_ADMIN).
>>>>
>>>> Cc: Alexei Starovoitov <ast@kernel.org>
>>>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>>>> Reported-by: John Stultz <john.stultz@linaro.org>
>>>> Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF")
>>>> Signed-off-by: Maciej Żenczykowski <maze@google.com>
>>>
>>> Thanks so much for helping narrow this regression down and submitting this fix!
>>> It's much appreciated!
>>>
>>> Tested-by: John Stultz <john.stultz@linaro.org>
>>
>> Applied to bpf tree. Thanks
> 
> Hey all,
>    Just wanted to follow up on this as I've not seen the regression fix
> land in 5.8-rc4 yet? Is it still pending, or did it fall through a
> gap?

No, it's in DaveM's -net tree currently, will go to Linus' tree on his next pull req:

   https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b338cb921e6739ff59ce32f43342779fe5ffa732

Re: [PATCH bpf v2] restore behaviour of CAP_SYS_ADMIN allowing the loading of networking bpf programs

[John Stultz]

On Mon, Jul 6, 2020 at 1:15 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 7/6/20 10:11 PM, John Stultz wrote:
> >    Just wanted to follow up on this as I've not seen the regression fix
> > land in 5.8-rc4 yet? Is it still pending, or did it fall through a
> > gap?
>
> No, it's in DaveM's -net tree currently, will go to Linus' tree on his next pull req:
>
>    https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b338cb921e6739ff59ce32f43342779fe5ffa732

Great! Much appreciated! Sorry to nag!
-john