Message-ID: <CAHC9VhQqgau3rL2182bVzONHqnfN2CtCT5hz29CVzYi=gpX6+A@mail.gmail.com>
Date:   Wed, 26 Apr 2023 16:49:23 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Matthieu Baerts <matthieu.baerts@...sares.net>
Cc:     James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Eric Paris <eparis@...isplace.org>,
        Paolo Abeni <pabeni@...hat.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Ondrej Mosnacek <omosnace@...hat.com>, mptcp@...ts.linux.dev,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        linux-security-module@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH LSM 0/2] security: SELinux/LSM label with MPTCP and accept

On Thu, Apr 20, 2023 at 12:55 PM Matthieu Baerts
<matthieu.baerts@...sares.net> wrote:
> On 19/04/2023 23:30, Paul Moore wrote:
> > On Wed, Apr 19, 2023 at 1:44 PM Matthieu Baerts
> > <matthieu.baerts@...sares.net> wrote:
> >>
> >> In [1], Ondrej Mosnacek explained they discovered the (userspace-facing)
> >> sockets returned by accept(2) when using MPTCP always end up with the
> >> label representing the kernel (typically system_u:system_r:kernel_t:s0),
> >> while it would make more sense to inherit the context from the parent
> >> socket (the one that is passed to accept(2)). Thanks to the
> >> participation of Paul Moore in the discussions, modifications on MPTCP
> >> side have started and the result is available here.
> >>
> >> Paolo Abeni worked hard to refactor the initialisation of the first
> >> subflow of a listen socket. The first subflow allocation is no longer
> >> done at the initialisation of the socket but later, when the connection
> >> request is received or when requested by the userspace. This was a
> >> prerequisite to proper support of SELinux/LSM labels with MPTCP and
> >> accept. The last batch containing the commit ddb1a072f858 ("mptcp: move
> >> first subflow allocation at mpc access time") [2] has been recently
> >> accepted and applied in netdev/net-next repo [3].
> >>
> >> This series of 2 patches is based on top of the lsm/next branch. Despite
> >> the fact they depend on commits that are in netdev/net-next repo to
> >> support the new feature, they can be applied in lsm/next without
> >> creating conflicts with net-next or causing build issues. These two
> >> patches on top of lsm/next still passes all the MPTCP-specific tests.
> >> The only thing is that the new feature only works properly with the
> >> patches that are on netdev/net-next. The tests with the new labels have
> >> been done on top of them.
> >>
> >> It then looks OK to us to send these patches for review on your side. We
> >> hope that's OK for you as well. If the patches look good to you and if
> >> you prefer, it is fine to apply these patches before or after having
> >> synced the lsm/next branch with Linus' tree when it will include the
> >> modifications from the netdev/net-next repo.
> >>
> >> Regarding the two patches, the first one introduces a new LSM hook
> >> called from MPTCP side when creating a new subflow socket. This hook
> >> allows the security module to relabel the subflow according to the owing
> >> process. The second one implements this new hook on the SELinux side.
> >
> > Thank you so much for working on this, I really appreciate the help!
>
> Thank you for the review!
>
> We are working on a v2 addressing your comments.

Thanks for getting v2 out so quickly.  I'm getting caught up on other
issue while we're in the merge window right now, but I'll give the v2
patchset a look in the not-to-distant future.  I'm fairly confident
we'll get it merged this dev cycle.

> Just one small detail regarding these comments: I hope you don't mind if
> we use "MPTCP socket" instead of "main MPTCP socket". Per connection,
> there is one MPTCP socket and possibly multiple subflow (TCP) sockets.
> There is then no concept of "main MPTCP socket".

Sure, no problem.

> > As far as potential merge issues with netdev/net-next and lsm/next, I
> > think we'll be okay.  I have a general policy[1] of not accepting new
> > patchsets, unless critical bugfixes, past rc5/rc6 so this would be
> > merged into lsm/next *after* the current merge window closes and
> > presumably after the netdev/net-next branch finds its way into Linus'
> > tree.
>
> It makes sense, we understand. These two patches were ready for a bit of
> time but we wanted to send them only after the prerequisite commits
> applied in net-next first. But that got delayed because we had a couple
> of nasty issues with them :)
>
> We hope it will not be an issue for you to maintain them in your tree
> for a couple of months but we tried to minimised the modifications in
> MPTCP code. Do not hesitate to reach us if there are some issues with them!

No worries, I'm happy to maintain them in either the LSM or the
SELinux tree (I'll need to remind myself of the changes to see which
is the best fit).

--
paul-moore.com

Powered by blists - more mailing lists