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

["Mickaël Salaün" <mic@digikod.net>]

On 20/12/2021 04:52, Konstantin Meskhidze wrote:
> 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.
> 

Allowing or forbidding socket creation is easy (and can also be done 
with seccomp), but it is not an access control per se (i.e. a socket 
doesn't give access to any data, but communicating with a peer does). 
Restricting access to network peers makes sense for Landlock, but not 
(only) file descriptor creation for now. In the future, this kind of 
restriction could make sense to implement Capsicum but it would probably 
be another interface.