From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <paul@paul-moore.com>
Cc: <andrii@kernel.org>, <ast@kernel.org>, <bpf@vger.kernel.org>,
<brauner@kernel.org>, <casey@schaufler-ca.com>,
<daniel@iogearbox.net>, <eddyz87@gmail.com>, <gnoack@google.com>,
<haoluo@google.com>, <jmorris@namei.org>,
<john.fastabend@gmail.com>, <jolsa@kernel.org>,
<kpsingh@kernel.org>, <kuni1840@gmail.com>, <kuniyu@amazon.com>,
<linux-security-module@vger.kernel.org>, <martin.lau@linux.dev>,
<mic@digikod.net>, <netdev@vger.kernel.org>,
<omosnace@redhat.com>, <sdf@fomichev.me>,
<selinux@vger.kernel.org>, <serge@hallyn.com>, <song@kernel.org>,
<stephen.smalley.work@gmail.com>, <yonghong.song@linux.dev>
Subject: Re: [PATCH v1 bpf-next 0/5] af_unix: Allow BPF LSM to scrub SCM_RIGHTS at sendmsg().
Date: Mon, 5 May 2025 17:35:10 -0700 [thread overview]
Message-ID: <20250506003514.66821-1-kuniyu@amazon.com> (raw)
In-Reply-To: <CAHC9VhSWS2L3qwu_r_1Fr3eLp-9KRz3_20EPwy=FFu7_eSiN7g@mail.gmail.com>
From: Paul Moore <paul@paul-moore.com>
Date: Mon, 5 May 2025 19:21:25 -0400
> On Mon, May 5, 2025 at 5:58 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >
> > As long as recvmsg() or recvmmsg() is used with cmsg, it is not
> > possible to avoid receiving file descriptors via SCM_RIGHTS.
> >
> > This behaviour has occasionally been flagged as problematic.
> >
> > For instance, as noted on the uAPI Group page [0], an untrusted peer
> > could send a file descriptor pointing to a hung NFS mount and then
> > close it. Once the receiver calls recvmsg() with msg_control, the
> > descriptor is automatically installed, and then the responsibility
> > for the final close() now falls on the receiver, which may result
> > in blocking the process for a long time.
> >
> > 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 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.
> >
> > This series allows BPF LSM to inspect skb at sendmsg() and scrub
> > SCM_RIGHTS fds by kfunc.
>
> I'll take a closer look later this week, but generally speaking LSM
> hooks are intended for observability and access control, not data
> modification, which means what you are trying to accomplish may not be
> a good fit for a LSM hook. Have you considered simply inspecting the
> skb at sendmsg() and rejecting the send in the LSM hook if a
> SCM_RIGHTS cmsg is present that doesn't fit within the security policy
> implemented in your BPF program?
I think the simple inspection (accept all or deny) does not cover
a real use case and is not that helpful.
I don't like to add another hook point in AF_UNIX code just because
of it and rather want to reuse the exisiting hook as we have a nice
place.
Also, passing skb makes it possible to build much more flexible
policy as it allows bpf prog to inspect the skb payload with
existing bpf helpers.
next prev parent reply other threads:[~2025-05-06 0:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-05 21:56 [PATCH v1 bpf-next 0/5] af_unix: Allow BPF LSM to scrub SCM_RIGHTS at sendmsg() Kuniyuki Iwashima
2025-05-05 21:56 ` [PATCH v1 bpf-next 1/5] af_unix: Call security_unix_may_send() in sendmsg() for all socket types Kuniyuki Iwashima
2025-05-05 21:56 ` [PATCH v1 bpf-next 2/5] af_unix: Pass skb to security_unix_may_send() Kuniyuki Iwashima
2025-05-05 21:56 ` [PATCH v1 bpf-next 3/5] af_unix: Remove redundant scm->fp check in __scm_destroy() Kuniyuki Iwashima
2025-05-09 14:13 ` kernel test robot
2025-05-05 21:56 ` [PATCH v1 bpf-next 4/5] bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may_send() Kuniyuki Iwashima
2025-05-06 0:13 ` Alexei Starovoitov
2025-05-06 8:25 ` Mickaël Salaün
2025-05-09 15:06 ` kernel test robot
2025-05-05 21:56 ` [PATCH v1 bpf-next 5/5] selftest: bpf: Add test for bpf_unix_scrub_fds() Kuniyuki Iwashima
2025-05-05 22:49 ` [PATCH v1 bpf-next 0/5] af_unix: Allow BPF LSM to scrub SCM_RIGHTS at sendmsg() Kumar Kartikeya Dwivedi
2025-05-06 0:21 ` Kuniyuki Iwashima
2025-05-06 16:25 ` Kumar Kartikeya Dwivedi
2025-05-06 18:16 ` Kuniyuki Iwashima
2025-05-06 9:15 ` Christian Brauner
2025-05-06 16:08 ` Kumar Kartikeya Dwivedi
2025-05-06 18:14 ` Kuniyuki Iwashima
2025-05-05 23:21 ` Paul Moore
2025-05-06 0:35 ` Kuniyuki Iwashima [this message]
2025-05-06 14:57 ` Paul Moore
2025-05-06 12:17 ` Lennart Poettering
2025-05-06 18:19 ` Kuniyuki Iwashima
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250506003514.66821-1-kuniyu@amazon.com \
--to=kuniyu@amazon.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=gnoack@google.com \
--cc=haoluo@google.com \
--cc=jmorris@namei.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuni1840@gmail.com \
--cc=linux-security-module@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mic@digikod.net \
--cc=netdev@vger.kernel.org \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--cc=sdf@fomichev.me \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=song@kernel.org \
--cc=stephen.smalley.work@gmail.com \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).