From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A531F16410; Fri, 12 Jan 2024 19:16:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KHKInoTS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9672C433F1; Fri, 12 Jan 2024 19:16:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705087019; bh=CUEpNXtIj3y2YghfDHeACDupq7CbR+GCqp5Oj2Kn0Tg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KHKInoTSQcHD/QPi8oCP9sqJFNb7MY1iMt8aZaXwcUcKrLOtwHGWP8gCe0B6ZnvI5 p6MdbRI9WZ0EU4zg5Fps+KrDi4bWz/M1gLkYOp4e3Ou5332D4FtGstAYgjfggYC3Hn qKud3prvJVCuRV8TMO1O0Xu15U1tv4jPFBAypq6CiqOyaDbLoxQAUjNILDEY+mXrFl MuXzPvQJ4I6W6RsYMs3zVBvutQsNfobH8N2gH3tB/2TsuIaFesy5VWXuUHRGZIe0ia SqVad8c3bOIpOYFW43f/bdYNExJOcGoM3xcVXbd7m3kJq4+xYkR3eNjojJAL6WTxOC mhpS2qzgklhQw== Date: Fri, 12 Jan 2024 20:16:53 +0100 From: Christian Brauner To: Andrii Nakryiko Cc: Linus Torvalds , Andrii Nakryiko , bpf@vger.kernel.org, netdev@vger.kernel.org, paul@paul-moore.com, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH bpf-next 03/29] bpf: introduce BPF token object Message-ID: <20240112-hetzt-gepard-5110cf759a34@brauner> References: <20240108-gasheizung-umstand-a36d89ed36b7@brauner> <20240109-tausend-tropenhelm-2a9914326249@brauner> <20240110-nervt-monopol-6d307e2518f4@brauner> <20240111-amten-stiefel-043027f9520f@brauner> <20240112-unpraktisch-kuraufenthalt-4fef655deab2@brauner> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: > > 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.