netdev - Re: [PATCH bpf-next 03/29] bpf: introduce BPF token object

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 12 Jan 2024 20:16:53 +0100
From: Christian Brauner <brauner@...nel.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Linus Torvalds <torvalds@...uxfoundation.org>, 
	Andrii Nakryiko <andrii@...nel.org>, bpf@...r.kernel.org, netdev@...r.kernel.org, paul@...l-moore.com, 
	linux-fsdevel@...r.kernel.org, linux-security-module@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH bpf-next 03/29] bpf: introduce BPF token object

> > My point is that the capable logic will walk upwards the user namespace
> > hierarchy from the token->userns until the user namespace of the caller
> > and terminate when it reached the init_user_ns.
> >
> > A caller is located in some namespace at the point where they call this
> > function. They provided a token. The caller isn't capable in the
> > namespace of the token so the function falls back to init_user_ns. Two
> > interesting cases:
> >
> > (1) The caller wasn't in an ancestor userns of the token. If that's the
> >     case then it follows that the caller also wasn't in the init_user_ns
> >     because the init_user_ns is a descendant of all other user
> >     namespaces. So falling back will fail.
> 
> agreed
> 
> >
> > (2) The caller was in the same or an ancestor user namespace of the
> >     token but didn't have the capability in that user namespace:
> >
> >      (i) They were in a non-init_user_ns. Therefore they can't be
> >          privileged in init_user_ns.
> >     (ii) They were in init_user_ns. Therefore, they lacked privileges in
> >          the init_user_ns.
> >
> > In both cases your fallback will do nothing iiuc.
> 
> agreed as well
> 
> And I agree in general that there isn't a *practically useful* case
> where this would matter much. But there is still (at least one) case
> where there could be a regression: if token is created in
> init_user_ns, caller has CAP_BPF in init_user_ns, caller passes that
> token to BPF_PROG_LOAD, and LSM policy rejects that token in
> security_bpf_token_capable(). Without the above implementation such
> operation will be rejected, even though if there was no token passed
> it would succeed. With my implementation above it will succeed as
> expected.

If that's the case then prevent the creation of tokens in the
init_user_ns and be done with it. If you fallback anyway then this is
the correct solution.

Make this change, please. I'm not willing to support this weird fallback
stuff which is even hard to reason about.