[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhR68fw+0oaenL08tRecLEC_oCdYcfGaN_m6PW3KZYtdTQ@mail.gmail.com>
Date: Wed, 19 Apr 2023 17:30:06 -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 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!
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
Powered by blists - more mailing lists