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 6149F216399; Tue, 6 May 2025 08:56:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746521792; cv=none; b=UFh7H8BMPjcjdWbret/ZpW1C6nnA/dzDW2S24Hf/6NRLZzfEOpawKzutT9SlCPCDnXHMzoS/NSPZZ71WpAWKdoitTaF5U4qm54eKhqpwJPggrVyD8E9yO75eT7f33sw5paDcU+0w4eH6ExfLR7Q99SE4zskUumqH2cD5jEQYPws= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746521792; c=relaxed/simple; bh=qVZHyp88JCrxll1HUvVH3F1uXrcyk8ebeewT3tzyUyA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qzsUOMEf0+NQmpBBy1FdwExzaYMaBrIUtQrma1ph9g6EBqvXDDrFGQMOr6kuITWbY6vht5B+/LRTufSXL8rFHLHKQ2immyR73JCX9U+4WPfVUEYchCUg0PQLVLBvN/aBt/pi+UR7RlMfl9S2Q6ak6AvG2UShJsmnPH9KbomU5n4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XgSh9qd7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XgSh9qd7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 942C1C4CEE4; Tue, 6 May 2025 08:56:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746521792; bh=qVZHyp88JCrxll1HUvVH3F1uXrcyk8ebeewT3tzyUyA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XgSh9qd7o2kNDeo3OZ+KzR2Pj1P3AWvczzbjaZsNdGHLLQEY7U0W7rlgoxK1ZB3cl maLmSuhUMRUwgN4Qxu4xYtL4lj3YOPUREkn9rWTYOA0zPoChgB+pWtVT2Rxnqgf1rD 5+P31LzmokYMJaeO5REpDL5haNaV2ElYHtFBsU2JJn4A7S37KDnyrijUBnWJx/s8Rf xMYF1INca9XnqdgE5lRtrWXCGogfSnS3D3DDVMQXZXYiqoxVymjVAHIaQdI/oDibKt hojwZ6N+t0bqNv2Am+ZI0xYhw3VmScrEO0jI6L51qlcNZH/kO94OzqY6lQc8SxXc5y O2/MxKpKkKw3A== Date: Tue, 6 May 2025 10:56:23 +0200 From: Christian Brauner To: Alexei Starovoitov Cc: Kuniyuki Iwashima , Alexei Starovoitov , Andrii Nakryiko , bpf , Casey Schaufler , Daniel Borkmann , Eduard , =?utf-8?Q?G=C3=BCnther?= Noack , Hao Luo , James Morris , John Fastabend , Jiri Olsa , KP Singh , Kuniyuki Iwashima , LSM List , Martin KaFai Lau , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , Network Development , Ondrej Mosnacek , Paul Moore , Stanislav Fomichev , selinux@vger.kernel.org, "Serge E . Hallyn" , Song Liu , Stephen Smalley , Yonghong Song Subject: Re: [PATCH v1 bpf-next 4/5] bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may_send(). Message-ID: <20250506-gehirn-festplatten-6ee995a756b7@brauner> References: <20250506004550.67917-1-kuniyu@amazon.com> Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, May 05, 2025 at 05:56:49PM -0700, Alexei Starovoitov wrote: > On Mon, May 5, 2025 at 5:46 PM Kuniyuki Iwashima wrote: > > > > From: Alexei Starovoitov > > Date: Mon, 5 May 2025 17:13:32 -0700 > > > On Mon, May 5, 2025 at 3:00 PM Kuniyuki Iwashima wrote: > > > > > > > > As Christian Brauner said [0], systemd calls cmsg_close_all() [1] after > > > > each recvmsg() to close() unwanted file descriptors sent via SCM_RIGHTS. > > > > > > > > However, this cannot work around the issue that close() for unwanted file > > > > descriptors could block longer because the last fput() could occur on > > > > the receiver side once sendmsg() with SCM_RIGHTS succeeds. > > > > > > > > Also, even filtering by LSM at recvmsg() does not work for the same reason. > > > > > > > > Thus, we need a better way to filter SCM_RIGHTS on the sender side. > > > > > > > > Let's add a new kfunc to scrub all file descriptors from skb in > > > > sendmsg(). > > > > > > > > This allows the receiver to keep recv()ing the bare data and disallows > > > > the sender to impose the potential slowness of the last fput(). > > > > > > > > If necessary, we can add more granular filtering per file descriptor > > > > after refactoring GC code and adding some fd-to-file helpers for BPF. > > > > > > > > Sample: > > > > > > > > SEC("lsm/unix_may_send") > > > > int BPF_PROG(unix_scrub_scm_rights, > > > > struct socket *sock, struct socket *other, struct sk_buff *skb) > > > > { > > > > struct unix_skb_parms *cb; > > > > > > > > if (skb && bpf_unix_scrub_fds(skb)) > > > > return -EPERM; > > > > > > > > return 0; > > > > } > > > > > > Any other programmability do you need there? > > > > This is kind of PoC, and as Kumar mentioned, per-fd scrubbing > > is ideal to cover the real use cases. > > > > https://lore.kernel.org/netdev/CAP01T77STmncrPt=BsFfEY6SX1+oYNXhPeZ1HC9J=S2jhOwQoQ@mail.gmail.com/ > > > > for example: > > https://uapi-group.org/kernel-features/#filtering-on-received-file-descriptors > > Fair enough. > Would be great to have them as selftests to make sure that advanced > use cases are actually working. I think we should do both a socket option and the bpf fd filtering. They can compliment each other. We should not force the use of bpf for this. This is a very basic security guarantee we want that shouldn't require the involvement of any LSM whatsoever.