Re: [PATCHv2 net 4/4] security: implement sctp_assoc_established hook in selinux

[Paul Moore <paul@paul-moore.com>]

On Thu, Nov 4, 2021 at 3:49 PM Xin Long <lucien.xin@gmail.com> wrote:
> On Thu, Nov 4, 2021 at 3:10 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Thu, Nov 4, 2021 at 7:02 AM David Miller <davem@davemloft.net> wrote:
> > > From: Paul Moore <paul@paul-moore.com>
> > > Date: Wed, 3 Nov 2021 23:17:00 -0400
> > > >
> > > > While I understand you did not intend to mislead DaveM and the netdev
> > > > folks with the v2 patchset, your failure to properly manage the
> > > > patchset's metadata *did* mislead them and as a result a patchset with
> > > > serious concerns from the SELinux side was merged.  You need to revert
> > > > this patchset while we continue to discuss, develop, and verify a
> > > > proper fix that we can all agree on.  If you decide not to revert this
> > > > patchset I will work with DaveM to do it for you, and that is not
> > > > something any of us wants.
> > >
> > > I would prefer a follow-up rathewr than a revert at this point.
> > >
> > > Please work with Xin to come up with a fix that works for both of you.
> >
> > We are working with Xin (see this thread), but you'll notice there is
> > still not a clear consensus on the best path forward.  The only thing
> > I am clear on at this point is that the current code in linux-next is
> > *not* something we want from a SELinux perspective.  I don't like
> > leaving known bad code like this in linux-next for more than a day or
> > two so please revert it, now.  If your policy is to merge substantive
> > non-network subsystem changes into the network tree without the proper
> > ACKs from the other subsystem maintainers, it would seem reasonable to
> > also be willing to revert those patches when the affected subsystems
> > request it.
> >
> > I understand that if a patchset is being ignored you might feel the
> > need to act without an explicit ACK, but this particular patchset
> > wasn't even a day old before you merged into the netdev tree.  Not to
> > mention that the patchset was posted during the second day of the
> > merge window, a time when many maintainers are busy testing code,
> > sending pull requests to Linus, and generally managing merge window
> > fallout.
>
> Hi Paul,
>
> It's applied on net tree, I think mostly because I posted this on net.git tree.
> Also, it's well related to the network part and affects SCTP protocol
> quite a lot.

Yes, I know it is in the net tree, that is how it made its way into
linux-next.  I wouldn't have merged it yet, and if not me who else
would have merged it beside the netdev folks?

Am I misunderstanding your comment?

> I wanted to post it on selinux tree: pcmoore/selinux.git, but I noticed the
> commit on top is written in 2019:
>
> commit 6e6934bae891681bc23b2536fff20e0898683f2c (HEAD -> main,
> origin/main, origin/HEAD)
> Author: Paul Moore <paul@paul-moore.com>
> Date:   Tue Sep 17 15:02:56 2019 -0400
>
>     selinux: add a SELinux specific README.md
>
>     DO NOT SUBMIT UPSTREAM
>
> Then I thought this tree was no longer active, sorry about that.

Like many kernel trees the default/main branch for the SELinux tree
doesn't contain anything useful, for the SELinux tree (and audit for
that matter) it is basically just the most recent major/minor tag from
Linus tree with a single tree specific README.md file patch so that
the GitHub mirror has a pretty landing page and a canonical reference
for how the tree is maintained.

* https://github.com/SELinuxProject/selinux-kernel

The general approach to the SELinux tree, as documented in the
README.md, is to do all of the linux-next work in the selinux/next
branch with the stable work happening in the selinux/stable-X.Y
branches.

FWIW, once we've resolved things I would be happy to have the patchset
live in the SELinux tree as opposed to the netdev tree.

-- 
paul moore
www.paul-moore.com