[PATCH v2 2/2] selinux: Implement mptcp_add_subflow hook

[Paul Moore]

On Mon, Jan 9, 2023 at 5:31 AM Paolo Abeni <pabeni at redhat.com> wrote:
> Hello,
>
> I'm sorry for the long delay:  I was on PTO with limited internet
> access.

No worries, I hear even kernel developers are allowed to take time off
occasionally ... at least that's what they tell me ;)

(I hope you're enjoying the time away!)

> On Fri, 2022-12-23 at 12:11 -0500, Paul Moore wrote:
> > On Thu, Dec 22, 2022 at 10:57 AM Paolo Abeni <pabeni at redhat.com> wrote:
> > > On Wed, 2022-12-21 at 20:21 -0500, Paul Moore wrote:
> > > > On Wed, Dec 21, 2022 at 2:24 PM Paolo Abeni <pabeni at redhat.com> wrote:

...

> > I generally take the long term view when it comes to Linux Kernel
> > development; given the nature of the kernel, and all the constraints
> > that come with it, I would much rather pursue solutions that we
> > believe have the longest staying power.
> >
> > I'm also happy to work on, and/or review, LSM patches in conjunction
> > with a MPTCP refactor.  If the only reason to split the work over two
> > kernel releases is to soften the blow during the merge window, I think
> > we can work that out in a single release ... at least I say that now
> > :)
>
> I thought about doing the MPTCP and selinux patches sequentially to
> both avoid the possibly untrivial conflicts resultion issues and to
> ensure that the mptcp patches are in place when the selinux ones are
> applied, as there is a fuctional dependency.

Sure, when working across subsystems there is usually some sort of
dependency challenge which dictates which side is tackled first, I
just wanted to make sure we don't consider one side "done" until we
finish both sides.

> > Basically when it comes down to it, I want to make sure that any fix
> > we come up with *works*.  In my mind that means doing the LSM fix in
> > conjunction with the rework; I would hate to see all of the rework
> > happen only to find out later that it still didn't solve the LSM
> > problem.
> >
> > Does that make sense?
>
> Indeed it makes sense to me.
>
> I think we can address that concern in a quite consolidated way. We
> usually include in the MPTCP tree a (very limited) number of patches
> that will not be submitted to the netdev because belong to other trees
> and/or are handled/owned by others devel.
>
> We use the above e.g. to fix build and/or functional issues in our
> self-tests caused by other subsystems without the need to wait for the
> proper fix to land into vanilla. When such event happen, we simply drop
> the local copy of the fixup patch.
>
> We could use a similar schema in this scenario. We can include the the
> LSM patches to the mptcp in our tree while the rework is in progress to
> ensure that overall the effort really addresses the LSM issue.
>
> We can rebase the LSM patches as needed to address conflicts as
> needed/if/when they pops up.
>
> Once that the mptcp patches will land into the LSM tree, we will submit
> formally the LSM ones to you. During the process I'll check and ensure
> that the LSM issue is really/still fixed. Would that work for you?

Sure, I'm pretty flexible on how we do these things, I just want it to
end up fixed in Linus' tree and there are plenty of ways we can make
that happen :)

> > > If that would prove to be the most reasonable option, could we consider
> > > to transiently merge first something alike:
> > >
> > > https://lore.kernel.org/mptcp/CAHC9VhSQnhH3UL4gqzu+YiA1Q3YyLLCv88gLJOvw-0+uw5Lvkw@mail.gmail.com/T/#m06c612f84f6b6fe759e670573b2c8092df71607b
> > >
> > > to have a workable short-term solution, and later revert it when the
> > > final solution would be in place?
> >
> > I would need to go back through that to make sure that it makes sense,
> > and ensure that the hook is idempotent for SELinux, AppArmor, and
> > Smack (current hook implementations), *aaaand* if we promise that this
> > is just a *temporary* hack I think I would be okay with that.
>
> I would appreciate that addtional extra mile a lot, as it will allow a
> (temporary!) fix to be delivered quite earlier than what the above
> process will provide.
>
> Of course the deal is that I'll take ownership of pursuing the complete
> fix till resolution.

Okay, let me do the investigation mentioned above to make sure this is
possible and report back (I need to refresh my memory first, the
holiday break kinda flushed this out of my mind ;).

-- 
paul-moore.com