> > 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.
