netdev - Re: [PATCH v1 bpf-next 4/5] bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250506004550.67917-1-kuniyu@amazon.com>
Date: Mon, 5 May 2025 17:44:13 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <ast@...nel.org>
CC: <andrii@...nel.org>, <bpf@...r.kernel.org>, <brauner@...nel.org>,
	<casey@...aufler-ca.com>, <daniel@...earbox.net>, <eddyz87@...il.com>,
	<gnoack@...gle.com>, <haoluo@...gle.com>, <jmorris@...ei.org>,
	<john.fastabend@...il.com>, <jolsa@...nel.org>, <kpsingh@...nel.org>,
	<kuni1840@...il.com>, <kuniyu@...zon.com>,
	<linux-security-module@...r.kernel.org>, <martin.lau@...ux.dev>,
	<mic@...ikod.net>, <netdev@...r.kernel.org>, <omosnace@...hat.com>,
	<paul@...l-moore.com>, <sdf@...ichev.me>, <selinux@...r.kernel.org>,
	<serge@...lyn.com>, <song@...nel.org>, <stephen.smalley.work@...il.com>,
	<yonghong.song@...ux.dev>
Subject: Re: [PATCH v1 bpf-next 4/5] bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may_send().

From: Alexei Starovoitov <alexei.starovoitov@...il.com>
Date: Mon, 5 May 2025 17:13:32 -0700
> On Mon, May 5, 2025 at 3:00 PM Kuniyuki Iwashima <kuniyu@...zon.com> 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

"""
An alternative to the previous item could be if some form of filtering
could be enforced on the file descriptors suitable for enqueuing on the
AF_UNIX socket. i.e. allow filtering by superblock type or similar, so
that policies such as “only memfds are OK to be received” may be
expressed. (BPF?).
"""

I think Christian can add more scenarios if needed.



> 
> If not and above is all that is needed then what Jann proposed
> sounds like better path to me:
> "
> I think the thorough fix would probably be to introduce a socket
> option (controlled via setsockopt()) that already blocks the peer's
> sendmsg().
> "
> 
> Easier to operate and upriv process can use such setsockopt() too.