Message-ID: <103de503-be0e-2eb2-b6f0-88567d765148@huawei-partners.com>
Date: Wed, 29 Jan 2025 14:02:38 +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/29/2025 1:25 PM, Matthieu Baerts wrote:
> Hi Mikhail,
> 
> On 29/01/2025 10:52, Mikhail Ivanov wrote:
>> 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?
> 
> Yes, that's the same TCP connection, just without extra bit to be able
> to use multiple TCP connections associated to the same MPTCP one.

Indeed, so MPTCP communication should be restricted the same way as TCP.
AFAICS this should be intuitive for MPTCP users and it'll be better
to let userland define this dependency.

> 
>>>> * 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.
> 
> A "fallback" can happen on different occasions as mentioned in the
> RFC8684 [1], e.g.
> 
> - The client asks to use MPTCP, but the other peer doesn't support it:
> 
>    Client                Server
>    |     SYN + MP_CAPABLE     |
>    |------------------------->|
>    |         SYN/ACK          |
>    |<-------------------------|  => Fallback on the client side
>    |           ACK            |
>    |------------------------->|
> 
> - A middle box doesn't touch the 3WHS, but intercept the communication
> just after:
> 
>    Client                Server
>    |     SYN + MP_CAPABLE     |
>    |------------------------->|
>    |   SYN/ACK + MP_CAPABLE   |
>    |<-------------------------|
>    |     ACK + MP_CAPABLE     |
>    |------------------------->|
>    |        DSS + data        | => but the server doesn't receive the DSS
>    |------------------------->| => So fallback on the server side
>    |           ACK            |
>    |<-------------------------| => Fallback on the client side
> 
> - etc.
> 
> So the connect(), even in blocking mode, can be OK, but the "fallback"
> will happen later.

Thanks! Theoretical "socket transformation" control should cover all
these cases.

You mean that it might be reasonable for a Landlock policy to block
MPTCP fallback when establishing first sublflow (when client does not
receive MP_CAPABLE)?

> 
> Again, once the "fallback" has been done, it just means there will be no
> more MPTCP options in the TCP headers, and these TCP connections,
> created and controlled by the kernel, will continue as "plain" TCP
> connections. It simply means that the MPTCP connection will be
> restricted to one path, because it will not be possible to create
> additional paths any more without these MPTCP options in the initial path.

Correct, thanks

> 
> [1] https://datatracker.ietf.org/doc/html/rfc8684#name-fallback
> 
>>> (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.
> 
> Same here, this fallback can happen at different stages of the
> connection, e.g. the server, supporting MPTCP, can receive a SYN without
> MP_CAPABLE option ; or the 3WHS is OK, but the MPTCP options are
> stripped later.
> 
>>>> 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.
> 
> That's good if you use this hook then!
> 
> Cheers,
> Matt

Powered by blists - more mailing lists