Message-ID: <f6e72e71-c5ed-8a9c-f33e-f190a47b8c27@huawei-partners.com>
Date: Wed, 29 Jan 2025 12:52:00 +0300
From: Mikhail Ivanov <ivanov.mikhail1@...wei-partners.com>
To: Matthieu Baerts <matttbe@...nel.org>, Mickaël Salaün
	<mic@...ikod.net>
CC: <gnoack@...gle.com>, <willemdebruijn.kernel@...il.com>,
	<matthieu@...fet.re>, <linux-security-module@...r.kernel.org>,
	<netdev@...r.kernel.org>, <netfilter-devel@...r.kernel.org>,
	<yusongping@...wei.com>, <artem.kuzin@...wei.com>,
	<konstantin.meskhidze@...wei.com>, MPTCP Linux <mptcp@...ts.linux.dev>,
	<linux-nfs@...r.kernel.org>, Paul Moore <paul@...l-moore.com>
Subject: Re: [RFC PATCH v2 1/8] landlock: Fix non-TCP sockets restriction

On 1/28/2025 9:14 PM, Matthieu Baerts wrote:
> Hi Mikhail,
> 
> Sorry, I didn't follow all the discussions in this thread, but here are
> some comments, hoping this can help to clarify the MPTCP case.

Thanks a lot for sharing your knowledge, Matthieu!

> 
> On 28/01/2025 11:56, Mikhail Ivanov wrote:
>> On 1/27/2025 10:48 PM, Mickaël Salaün wrote:
> 
> (...)
> 
>>> I'm a bit worried that we miss some of these places (now or in future
>>> kernel versions).  We'll need a new LSM hook for that.
>>>
>>> Could you list the current locations?
>>
>> Currently, I know only about TCP-related transformations:
>>
>> * SMC can fallback to TCP during connection. TCP connection is used
>>    (1) to exchange CLC control messages in default case and (2) for the
>>    communication in the case of fallback. If socket was connected or
>>    connection failed, socket can not be reconnected again. There is no
>>    existing security hook to control the fallback case,
>>
>> * MPTCP uses TCP for communication between two network interfaces in the
>>    default case and can fallback to plain TCP if remote peer does not
>>    support MPTCP. AFAICS, there is also no security hook to control the
>>    fallback transformation,
> 
> There are security hooks to control the path creation, but not to
> control the "fallback transformation".
> 
> Technically, with MPTCP, the userspace will create an IPPROTO_MPTCP
> socket. This is only used "internally": to communicate between the
> userspace and the kernelspace, but not directly used between network
> interfaces. This "external" communication is done via one or multiple
> kernel TCP sockets carrying extra TCP options for the mapping. The
> userspace cannot directly control these sockets created by the kernel.
> 
> In case of fallback, the kernel TCP socket "simply" drop the extra TCP
> options needed for MPTCP, and carry on like normal TCP. So on the wire
> and in the Linux network stack, it is the same TCP connection, without
> the MPTCP options in the TCP header. The userspace continue to
> communicate with the same socket.
> 
> I'm not sure if there is a need to block the fallback: it means only one
> path can be used at a time.

You mean that users always rely on a plain TCP communication in the case
the connection of MPTCP multipath communication fails?

> 
>> * IPv6 -> IPv4 transformation for TCP and UDP sockets withon
>>    IPV6_ADDRFORM. Can be controlled with setsockopt() security hook.
>>
>> As I said before, I wonder if user may want to use SMC or MPTCP and deny
>> TCP communication, since he should rely on fallback transformation
>> during the connection in the common case. It may be unexpected for
>> connect(2) to fail during the fallback due to security politics.
> 
> With MPTCP, fallbacks can happen at the beginning of a connection, when
> there is only one path. This is done after the userspace's connect(). If
> the fallback is blocked, I guess the userspace will get the same errors
> as when an open connection is reset.

In the case of blocking due to security policy, userspace should get
-EACESS. I mean, the user might not expect the fallback path to be
blocked during the connection if he has allowed only MPTCP communication
using the Landlock policy.

> 
> (Note that on the listener side, the fallback can happen before the
> userspace's accept() which can even get an IPPROTO_TCP socket in return)

Indeed, fallback can happen on a server side as well.

> 
>> Theoretically, any TCP restriction should cause similar SMC and MPTCP
>> restriction. If we deny creation of TCP sockets, we should also deny
>> creation of SMC and MPTCP sockets. I thought that such dependencies may
>> be too complex and it will be better to leave them for the user and not
>> provide any transformation control at all. What do you think?
> I guess the creation of "kernel" TCP sockets used by MPTCP (and SMC?)
> can be restricted, it depends on where this hook is placed I suppose.

Calling
	socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP)
causes creation of kernel TCP socket, so we can use
security_socket_create() hook for this purpose.

> 
> (...)
> 
> Cheers,
> Matt

Powered by blists - more mailing lists