So, if I understand correctly, this should be simple for the Landlock socket creation control: we only check socket properties at creation time and we ignore potential fallbacks. This should be documented though. As an example, if a Landlock policies only allows MPTCP: socket(..., IPPROTO_MPTCP) should be allowed and any legitimate use of the returned socket (according to MPTCP) should be allowed, including TCP fallback. However, socket(..., IPPROTO_TCP/0), should only be allowed if TCP is explicitly allowed. This means that we might end up with an MPTCP socket only using TCP, which is OK. I guess this should be the same for other protocols, except if user space can explicitly transform a specific socket type to use an *arbitrary* protocol, but I think this is not possible. > > > > > > > > > > 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. > > > > Yes, I think that would make more sense. > > > > I guess we can look at MPTCP as TCP with extra features. > > Yeap > > > > > So if TCP is blocked, MPTCP should be blocked as well. (And eventually > > having the possibility to block only TCP but not MPTCP and the opposite, > > but that's a different topic: a possible new feature, but not a bug-fix) > What do you mean by the "bug fix"? > > > > > > > > > > * IPv6 -> IPv4 transformation for TCP and UDP sockets withon > > > > > > >    IPV6_ADDRFORM. Can be controlled with setsockopt() security hook. According to the man page: "It is allowed only for IPv6 sockets that are connected and bound to a v4-mapped-on-v6 address." This compatibility feature makes sense from user space point of view and should not result in an error because of Landlock. > > > > > > > > > > > > > > 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 A remaining question is then, can we repurpose an MPTCP socket that did fallback to TCP, to (re)connect to another destination (this time directly with TCP)? I guess this is possible. If it is the case, I think it should be OK anyway. That could be used by an attacker, but that should not give more access because of the MPTCP fallback mechanism anyway. We should see MPTCP as a superset of TCP. At the end, security policy is in the hands of user space. > > > > > > 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)? > > > > Personally, I don't even know if there is really a need for such > > policies. The fallback is there not to block a connection if the other > > peer doesn't support MPTCP, or if a middlebox decides to mess-up with > > MPTCP options. So instead of an error, the connection continues but is > > "degraded" by not being able to create multiple paths later on. I agree, this kind of compatibility feature should not be denied. > > > > Maybe best to wait for a concrete use-case before implementing this? > > Ok, got it! I agree that such policies does not seem to be useful. > > > > > (...) > > > > Cheers, > > Matt >
