Re: [RFC PATCH v2 1/8] landlock: Fix non-TCP sockets restriction
From: Mikhail Ivanov <hidden>
Date: 2025-01-31 11:04:57
Also in:
linux-nfs, mptcp, netdev, netfilter-devel
On 1/29/2025 5:51 PM, Mickaël Salaün wrote:>>>>>>> On 28/01/2025 11:56, Mikhail Ivanov wrote: [...]
quoted
quoted
quoted
quoted
quoted
quoted
quoted
* 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/