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.
Link: https://lore.kernel.org/netdev/CAFqZXNs2LF-OoQBUiiSEyranJUXkPLcCfBkMkwFeM6qEwMKCTw@mail.gmail.com/ [1]
Link: https://git.kernel.org/netdev/net-next/c/ddb1a072f858 [2]
Link: https://lore.kernel.org/netdev/20230414-upstream-net-next-20230414-mptcp-refactor-first-subflow-init-v1-0-04d177057eb9@tessares.net/ [3]
Signed-off-by: Matthieu Baerts <[email protected]>
---
Paolo Abeni (2):
security, lsm: Introduce security_mptcp_add_subflow()
selinux: Implement mptcp_add_subflow hook
include/linux/lsm_hook_defs.h | 1 +
include/linux/security.h | 6 ++++++
net/mptcp/subflow.c | 6 ++++++
security/security.c | 15 +++++++++++++++
security/selinux/hooks.c | 16 ++++++++++++++++
security/selinux/netlabel.c | 8 ++++++--
6 files changed, 50 insertions(+), 2 deletions(-)
---
base-commit: d82dcd9e21b77d338dc4875f3d4111f0db314a7c
change-id: 20230419-upstream-lsm-next-20230419-mptcp-sublows-user-ctx-eee658fafcba
Best regards,
--
Matthieu Baerts <[email protected]>
From: Paolo Abeni <[email protected]>
MPTCP can create subflows in kernel context, and later indirectly
expose them to user-space, via the owning mptcp socket.
As discussed in the reported link, the above causes unexpected failures
for server, MPTCP-enabled applications.
Let's introduce a new LSM hook to allow the security module to relabel
the subflow according to the owing process.
Note that the new hook requires both the mptcp socket and the new
subflow. This could allow future extensions, e.g. explicitly validating
the mptcp <-> subflow linkage.
Link: https://lore.kernel.org/mptcp/CAHC9VhTNh-YwiyTds=P1e3rixEDqbRTFj22bpya=+qJqfcaMfg@mail.gmail.com/
Signed-off-by: Paolo Abeni <[email protected]>
Acked-by: Matthieu Baerts <[email protected]>
Signed-off-by: Matthieu Baerts <[email protected]>
---
include/linux/lsm_hook_defs.h | 1 +
include/linux/security.h | 6 ++++++
net/mptcp/subflow.c | 6 ++++++
security/security.c | 15 +++++++++++++++
4 files changed, 28 insertions(+)
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 6bb55e61e8e8..7308a1a7599b 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -343,6 +343,7 @@ LSM_HOOK(void, LSM_RET_VOID, sctp_sk_clone, struct sctp_association *asoc,
struct sock *sk, struct sock *newsk)
LSM_HOOK(int, 0, sctp_assoc_established, struct sctp_association *asoc,
struct sk_buff *skb)
+LSM_HOOK(int, 0, mptcp_add_subflow, struct sock *sk, struct sock *ssk)
#endif /* CONFIG_SECURITY_NETWORK */
#ifdef CONFIG_SECURITY_INFINIBAND
diff --git a/include/linux/security.h b/include/linux/security.h
index cd23221ce9e6..80a0b37a9f26 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1465,6 +1465,7 @@ void security_sctp_sk_clone(struct sctp_association *asoc, struct sock *sk,
struct sock *newsk);
int security_sctp_assoc_established(struct sctp_association *asoc,
struct sk_buff *skb);
+int security_mptcp_add_subflow(struct sock *sk, struct sock *ssk);
#else /* CONFIG_SECURITY_NETWORK */
static inline int security_unix_stream_connect(struct sock *sock,
@@ -1692,6 +1693,11 @@ static inline int security_sctp_assoc_established(struct sctp_association *asoc,
{
return 0;
}
+
+static inline int security_mptcp_add_subflow(struct sock *sk, struct sock *ssk)
+{
+ return 0;
+}
#endif /* CONFIG_SECURITY_NETWORK */
#ifdef CONFIG_SECURITY_INFINIBAND
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 4ae1a7304cf0..d361749cabff 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -1692,6 +1692,10 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family,
lock_sock_nested(sf->sk, SINGLE_DEPTH_NESTING);
+ err = security_mptcp_add_subflow(sk, sf->sk);
+ if (err)
+ goto release_ssk;
+
/* the newly created socket has to be in the same cgroup as its parent */
mptcp_attach_cgroup(sk, sf->sk);
@@ -1704,6 +1708,8 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family,
get_net_track(net, &sf->sk->ns_tracker, GFP_KERNEL);
sock_inuse_add(net, 1);
err = tcp_set_ulp(sf->sk, "mptcp");
+
+release_ssk:
release_sock(sf->sk);
if (err) {
diff --git a/security/security.c b/security/security.c
index f4170efcddda..24cf2644a4b9 100644
--- a/security/security.c
+++ b/security/security.c
@@ -4667,6 +4667,21 @@ int security_sctp_assoc_established(struct sctp_association *asoc,
}
EXPORT_SYMBOL(security_sctp_assoc_established);
+/**
+ * security_mptcp_add_subflow() - Inherit the LSM label from the MPTCP socket
+ * @sk: the owning MPTCP socket
+ * @ssk: the new subflow
+ *
+ * Update the labeling for the given MPTCP subflow, to match the one of the
+ * owning MPTCP socket.
+ *
+ * Return: Returns 0 on success or a negative error code on failure.
+ */
+int security_mptcp_add_subflow(struct sock *sk, struct sock *ssk)
+{
+ return call_int_hook(mptcp_add_subflow, 0, sk, ssk);
+}
+
#endif /* CONFIG_SECURITY_NETWORK */
#ifdef CONFIG_SECURITY_INFINIBAND
--
2.39.2
From: Paolo Abeni <[email protected]>
Newly added subflows should inherit the LSM label from the associated
msk socket regarless current context.
This patch implements the above copying sid and class from the msk
context, deleting the existing subflow label, if any, and then
re-creating a new one.
The new helper reuses the selinux_netlbl_sk_security_free() function,
and the latter can end-up being called multiple times with the same
argument; we additionally need to make it idempotent.
Signed-off-by: Paolo Abeni <[email protected]>
Acked-by: Matthieu Baerts <[email protected]>
Signed-off-by: Matthieu Baerts <[email protected]>
---
security/selinux/hooks.c | 16 ++++++++++++++++
security/selinux/netlabel.c | 8 ++++++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 9a5bdfc21314..53cfc1cb67d2 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5476,6 +5476,21 @@ static void selinux_sctp_sk_clone(struct sctp_association *asoc, struct sock *sk
selinux_netlbl_sctp_sk_clone(sk, newsk);
}
+static int selinux_mptcp_add_subflow(struct sock *sk, struct sock *ssk)
+{
+ struct sk_security_struct *ssksec = ssk->sk_security;
+ struct sk_security_struct *sksec = sk->sk_security;
+
+ ssksec->sclass = sksec->sclass;
+ ssksec->sid = sksec->sid;
+
+ /* replace the existing subflow label deleting the existing one
+ * and re-recrating a new label using the current context
+ */
+ selinux_netlbl_sk_security_free(ssksec);
+ return selinux_netlbl_socket_post_create(ssk, ssk->sk_family);
+}
+
static int selinux_inet_conn_request(const struct sock *sk, struct sk_buff *skb,
struct request_sock *req)
{
@@ -7216,6 +7231,7 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(sctp_sk_clone, selinux_sctp_sk_clone),
LSM_HOOK_INIT(sctp_bind_connect, selinux_sctp_bind_connect),
LSM_HOOK_INIT(sctp_assoc_established, selinux_sctp_assoc_established),
+ LSM_HOOK_INIT(mptcp_add_subflow, selinux_mptcp_add_subflow),
LSM_HOOK_INIT(inet_conn_request, selinux_inet_conn_request),
LSM_HOOK_INIT(inet_csk_clone, selinux_inet_csk_clone),
LSM_HOOK_INIT(inet_conn_established, selinux_inet_conn_established),
diff --git a/security/selinux/netlabel.c b/security/selinux/netlabel.c
index 1321f15799e2..33187e38def7 100644
--- a/security/selinux/netlabel.c
+++ b/security/selinux/netlabel.c
@@ -155,8 +155,12 @@ void selinux_netlbl_err(struct sk_buff *skb, u16 family, int error, int gateway)
*/
void selinux_netlbl_sk_security_free(struct sk_security_struct *sksec)
{
- if (sksec->nlbl_secattr != NULL)
- netlbl_secattr_free(sksec->nlbl_secattr);
+ if (!sksec->nlbl_secattr)
+ return;
+
+ netlbl_secattr_free(sksec->nlbl_secattr);
+ sksec->nlbl_secattr = NULL;
+ sksec->nlbl_state = NLBL_UNSET;
}
/**
--
2.39.2
On Wed, Apr 19, 2023 at 1:44 PM Matthieu Baerts
<[email protected]> 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
On Wed, Apr 19, 2023 at 1:44 PM Matthieu Baerts
<[email protected]> wrote:
>
> From: Paolo Abeni <[email protected]>
>
> MPTCP can create subflows in kernel context, and later indirectly
> expose them to user-space, via the owning mptcp socket.
>
> As discussed in the reported link, the above causes unexpected failures
> for server, MPTCP-enabled applications.
>
> Let's introduce a new LSM hook to allow the security module to relabel
> the subflow according to the owing process.
"... according to the main MPTCP socket."
You might also want to stick with a consistent capitalization of
"MPTCP" in the commit description, but that is being *really* nitpicky
on my part ;)
There is a suggestion for some additional comments in the hook's
description below, but otherwise this looks good to me.
> Note that the new hook requires both the mptcp socket and the new
> subflow. This could allow future extensions, e.g. explicitly validating
> the mptcp <-> subflow linkage.
>
> Link: https://lore.kernel.org/mptcp/CAHC9VhTNh-YwiyTds=P1e3rixEDqbRTFj22bpya=+qJqfcaMfg@mail.gmail.com/
> Signed-off-by: Paolo Abeni <[email protected]>
> Acked-by: Matthieu Baerts <[email protected]>
> Signed-off-by: Matthieu Baerts <[email protected]>
> ---
> include/linux/lsm_hook_defs.h | 1 +
> include/linux/security.h | 6 ++++++
> net/mptcp/subflow.c | 6 ++++++
> security/security.c | 15 +++++++++++++++
> 4 files changed, 28 insertions(+)
...
> diff --git a/security/security.c b/security/security.c
> index f4170efcddda..24cf2644a4b9 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -4667,6 +4667,21 @@ int security_sctp_assoc_established(struct sctp_association *asoc,
> }
> EXPORT_SYMBOL(security_sctp_assoc_established);
>
> +/**
> + * security_mptcp_add_subflow() - Inherit the LSM label from the MPTCP socket
> + * @sk: the owning MPTCP socket
> + * @ssk: the new subflow
> + *
> + * Update the labeling for the given MPTCP subflow, to match the one of the
> + * owning MPTCP socket.
I would add a sentence at the end making it clear that this hook is
called after the socket has been created and initialized via the
security_socket_create() and security_socket_post_create() LSM hooks.
> + *
> + * Return: Returns 0 on success or a negative error code on failure.
> + */
> +int security_mptcp_add_subflow(struct sock *sk, struct sock *ssk)
> +{
> + return call_int_hook(mptcp_add_subflow, 0, sk, ssk);
> +}
> +
> #endif /* CONFIG_SECURITY_NETWORK */
>
> #ifdef CONFIG_SECURITY_INFINIBAND
>
> --
> 2.39.2
--
paul-moore.com
On Wed, Apr 19, 2023 at 1:44 PM Matthieu Baerts
<[email protected]> wrote:
> From: Paolo Abeni <[email protected]>
>
> Newly added subflows should inherit the LSM label from the associated
> msk socket regarless current context.
"... from the associated main MPTCP socket regardless of the current context."
Us SELinux folks may not always be able to make the jump from "msk" to
"main MPTCP socket" when we are looking through the git log in the
future, let's make it easier on us/me ;)
> This patch implements the above copying sid and class from the msk
> context, deleting the existing subflow label, if any, and then
"... from the main MPTCP socket context, deleting ..."
> re-creating a new one.
>
> The new helper reuses the selinux_netlbl_sk_security_free() function,
> and the latter can end-up being called multiple times with the same
> argument; we additionally need to make it idempotent.
>
> Signed-off-by: Paolo Abeni <[email protected]>
> Acked-by: Matthieu Baerts <[email protected]>
> Signed-off-by: Matthieu Baerts <[email protected]>
> ---
> security/selinux/hooks.c | 16 ++++++++++++++++
> security/selinux/netlabel.c | 8 ++++++--
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 9a5bdfc21314..53cfc1cb67d2 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -5476,6 +5476,21 @@ static void selinux_sctp_sk_clone(struct sctp_association *asoc, struct sock *sk
> selinux_netlbl_sctp_sk_clone(sk, newsk);
> }
>
> +static int selinux_mptcp_add_subflow(struct sock *sk, struct sock *ssk)
> +{
> + struct sk_security_struct *ssksec = ssk->sk_security;
> + struct sk_security_struct *sksec = sk->sk_security;
> +
> + ssksec->sclass = sksec->sclass;
> + ssksec->sid = sksec->sid;
> +
> + /* replace the existing subflow label deleting the existing one
> + * and re-recrating a new label using the current context
"... new label using the updated context"
Let's avoid the phrase "current context" as that could imply the
current task, which is exactly what we are trying not to do.
> + */
> + selinux_netlbl_sk_security_free(ssksec);
> + return selinux_netlbl_socket_post_create(ssk, ssk->sk_family);
> +}
> +
--
paul-moore.com
Hi Paul,
On 19/04/2023 23:30, Paul Moore wrote:
> On Wed, Apr 19, 2023 at 1:44 PM Matthieu Baerts
> <[email protected]> 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.
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".
> 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!
Cheers,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
http://www.tessares.net
On Thu, Apr 20, 2023 at 12:55 PM Matthieu Baerts
<[email protected]> wrote:
> On 19/04/2023 23:30, Paul Moore wrote:
> > On Wed, Apr 19, 2023 at 1:44 PM Matthieu Baerts
> > <[email protected]> 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