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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c325e5f6-d8d5-b085-fd2d-7f454629a1ec@digikod.net>
Date:   Sat, 18 Dec 2021 12:01:15 +0100
From:   Mickaël Salaün <mic@...ikod.net>
To:     Konstantin Meskhidze <konstantin.meskhidze@...wei.com>
Cc:     yusongping <yusongping@...wei.com>,
        Artem Kuzin <artem.kuzin@...wei.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        "netfilter@...r.kernel.org" <netfilter@...r.kernel.org>,
        Willem de Bruijn <willemdebruijn.kernel@...il.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.