Hi, Mickaёl! -----Original Message----- From: Mickaël Salaün <mic@xxxxxxxxxxx> Sent: Saturday, December 18, 2021 7:01 PM To: Konstantin Meskhidze <konstantin.meskhidze@xxxxxxxxxx> Cc: yusongping <yusongping@xxxxxxxxxx>; Artem Kuzin <artem.kuzin@xxxxxxxxxx>; linux-security-module <linux-security-module@xxxxxxxxxxxxxxx>; Network Development <netdev@xxxxxxxxxxxxxxx>; netfilter@xxxxxxxxxxxxxxx; Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> Subject: Re: [RFC PATCH 0/2] Landlock network PoC implementation On 18/12/2021 09:26, Konstantin Meskhidze wrote: > Hi, Mickaёl > Thanks again for your opinion about minimal Landlock IPv4 network version. > I have already started refactoring the code. > Here are some additional thoughts about the design. [...] >>> >>> Accesses/suffixes should be: >>> - CREATE >>> - ACCEPT >>> - BIND >>> - LISTEN >>> - CONNECT >>> - RECEIVE (RECEIVE_FROM and SEND_TO should not be needed) >>> - SEND >>> - SHUTDOWN >>> - GET_OPTION (GETSOCKOPT) >>> - SET_OPTION (SETSOCKOPT) > >>> For now, the only access rights should be LANDLOCK_ACCESS_NET_BIND_TCP and LANDLOCK_ACCESS_NET_CONNECT_TCP (tie to two LSM hooks with struct sockaddr). > >>> These attribute and access right changes reduce the scope of the >>> network access control and make it simpler but still really useful. Datagram (e.g. UDP, which could add BIND_UDP and SEND_UDP) sockets will be more complex to restrict correctly and should then come in another patch series, once TCP is supported. > > I think that having access rights like LANDLOCK_ACCESS_NET_CREATE_TCP_SOCKET_DENY/LANDLOCK_ACCESS_NET_CREATE_UDP_SOCKET_DENY might be useful during initialization phase of container/sandbox, cause a user could have the possibility to restrict the creation of some type of sockets at all, and to reduce the attack surface related to security aspect. > So the logic could be the following: > 1. Process restricts creation UDP sockets, allows TCP one. > - LANDLOCK_ACCESS_NET_CREATE_*_SOCKET_DENY rules are tied to process task_struct cause there are no sockets inodes created at this moment. > 2. Creates necessary number of sockets. > 3. Restricts sockets' access rights. > - LANDLOCK_ACCESS_NET_BIND_* / LANDLOCK_ACCESS_NET_CONNECT_* access rights are tied to sockets inodes individually. > > Reducing the attack surface on the kernel is valuable but not the primary goal of Landlock. seccomp is designed for this task and a seccomp filters can easily forbid creation of specific sockets. We should consider using > both Landlock and seccomp, and your use case of denying UDP vs. TCP is good. > Anyway, the LANDLOCK_ACCESS_NET_CREATE_TCP_SOCKET_DENY name in not appropriate. Indeed, mixing "access" and "deny" doesn't make sense. A LANDLOCK_ACCESS_NET_CREATE_TCP access could be useful if > > we can define such TCP socket semantic, e.g. with a port, which is not possible when creating a socket, and it is OK. I think we can define if it’s a TCP or UDP socket in the moment of its creating using TYPE field in socket(domain, TYPE, protocol) function: - TCP services use SOCK_STREAM type. - UDP ones use SOCK_DGRAM type. So we can have LANDLOCK_ACCESS_NET_CREATE_TCP access rule in TCP socket semantic, and therefore check socket_create(domain, SOCK_STREAM, protocol) hook. The similar rule( LANDLOCK_ACCESS_NET_CREATE_UPD) could be used for recognizing UDP sockets in future patches.
