RE: [RFC PATCH 0/2] Landlock network PoC implementation

[Konstantin Meskhidze <konstantin.meskhidze@huawei.com>]

Hi, Mickaёl!

-----Original Message-----
From: Mickaël Salaün <mic@digikod.net> 
Sent: Saturday, December 18, 2021 7:01 PM
To: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Cc: yusongping <yusongping@huawei.com>; Artem Kuzin <artem.kuzin@huawei.com>; linux-security-module <linux-security-module@vger.kernel.org>; Network Development <netdev@vger.kernel.org>; netfilter@vger.kernel.org; Willem de Bruijn <willemdebruijn.kernel@gmail.com>
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.