[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250614204044.2190213-1-kuni1840@gmail.com>
Date: Sat, 14 Jun 2025 13:40:04 -0700
From: Kuniyuki Iwashima <kuni1840@...il.com>
To: paul@...l-moore.com
Cc: andrii@...nel.org,
ast@...nel.org,
bpf@...r.kernel.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@...gle.com,
linux-security-module@...r.kernel.org,
martin.lau@...ux.dev,
memxor@...il.com,
mic@...ikod.net,
netdev@...r.kernel.org,
omosnace@...hat.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 v2 bpf-next 0/4] af_unix: Allow BPF LSM to filter SCM_RIGHTS at sendmsg().
From: Paul Moore <paul@...l-moore.com>
Date: Sat, 14 Jun 2025 07:43:46 -0400
> On June 13, 2025 6:24:15 PM Kuniyuki Iwashima <kuni1840@...il.com> wrote:
> > From: Kuniyuki Iwashima <kuniyu@...gle.com>
> >
> > Since commit 77cbe1a6d873 ("af_unix: Introduce SO_PASSRIGHTS."),
> > we can disable SCM_RIGHTS per socket, but it's not flexible.
> >
> > This series allows us to implement more fine-grained filtering for
> > SCM_RIGHTS with BPF LSM.
>
> My ability to review this over the weekend is limited due to device and
> network access, but I'll take a look next week.
>
> That said, it would be good if you could clarify the "filtering" aspect of
> your comments; it may be obvious when I'm able to look at the full patchset
I meant to mention that just below the quoted part :)
---8<---
Changes:
v2: Remove SCM_RIGHTS fd scrubbing functionality
---8<---
> in context, but the commit descriptions worry me that perhaps you are still
> intending on using the LSM framework to cut SCM_RIGHTS payloads from
> individual messages? Blocking messages at send time if they contain
> SCM_RIGHTS is likely okay (pending proper implementation review), but
> modifying packets in flight in the LSM framework is not.
>
> Also, a quick administrative note, I see you have marked this as
> "bpf-next", however given the diffstat of the proposed changes this
> patchset should go to Linus via the LSM tree and not the BPF tree.
This was to kick the BPF CI for the selftest patch, and the __nullable
arg suffix in patch 3 is BPF specific stuff, but I don't have preference
here and whichever is fine to me.
Powered by blists - more mailing lists