Re: [PATCH LSM 0/2] security: SELinux/LSM label with MPTCP and accept

[Paul Moore]

On Wed, Apr 19, 2023 at 1:44 PM Matthieu Baerts
<matthieu.baerts@xxxxxxxxxxxx> 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!

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.

[1] https://github.com/LinuxSecurityModule/kernel/blob/main/README.md

--
paul-moore.com