[RFC PATCH v2 1/8] landlock: Fix non-TCP sockets restriction

[Mikhail Ivanov]

On 1/29/2025 5:51 PM, Mickaël Salaün wrote:>>>>>>> On 28/01/2025 11:56, 
Mikhail Ivanov wrote:

[...]

>>>>>>>> * 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.

IPV6_ADDRFORM is useful to pass IPv6 sockets binded and connected to
v4-mapped-on-v6 addresses to pure IPv4 applications [1].

I just realized we first need to consider restriction of IPv4 access
for IPv4/v6 dual stack. It's possible to communicate with IPv4 peer
using IPv6 socket (on client or server side) that is mapped on
v4-mapped-on-v6 address (RFC 3493 [2]). If socket access rights provide
separate control over IPv6 and IPv4, v4-mapped-on-v6 looks like possible
bypass of IPv4 restriction and violation of the least astonishment
principle.

This can be controlled with IPV6_V6ONLY socket option or with
net.ipv6.bindv6only sysctl knob. Restriction with sysctl knob is applied
globally and may break some dual-stack dependent applications.

I'm currently trying to collect real-world examples in which user may
want to allow IPv6-only communication in a sandboxed environment.
Theoretically, this can be seen as unprivileged reduction of attack
surface for IPv6-only programs in dual-stack network (disallow to open
IPv4 connections and communicate with loopback via IPv4 stack).

Earlier, it was also discussed about possible security issues on the
userland side related to different address representation and address
filtering [3]. But, I don't really think these are the good examples for
the motivation.

If the v4-mapped-on-v6 addressing control is deemed reasonable, it
should be better implemented with a new access right for
LANDLOCK_RULE_NET_PORT rather than a part of socket creation control.

[1] https://man7.org/linux/man-pages/man7/ipv6.7.html
[2] https://datatracker.ietf.org/doc/html/rfc3493#section-3.7
[3] https://lwn.net/Articles/688462/