[PATCH v9 00/12] Network support for Landlock - allowed list of protocols

[Mickaël Salaün]

On 28/06/2023 04:33, Jeff Xu wrote:
> On Mon, Jun 26, 2023 at 8:29 AM Mickaël Salaün <mic at digikod.net> wrote:
>>
>> Reviving Günther's suggestion to deny a set of network protocols:
>>
>> On 14/03/2023 14:28, Mickaël Salaün wrote:
>>>
>>> On 13/03/2023 18:16, Konstantin Meskhidze (A) wrote:
>>>>
>>>>
>>>> 2/24/2023 1:17 AM, Günther Noack пишет:
>>
>> [...]
>>
>>>>>
>>>>> * Given the list of obscure network protocols listed in the socket(2)
>>>>>       man page, I find it slightly weird to have rules for the use of TCP,
>>>>>       but to leave less prominent protocols unrestricted.
>>>>>
>>>>>       For example, a process with an enabled Landlock network ruleset may
>>>>>       connect only to certain TCP ports, but at the same time it can
>>>>>       happily use Bluetooth/CAN bus/DECnet/IPX or other protocols?
>>>>
>>>>          We also have started a discussion about UDP protocol, but it's
>>>> more complicated since UDP sockets does not establish connections
>>>> between each other. There is a performance problem on the first place here.
>>>>
>>>> I'm not familiar with Bluetooth/CAN bus/DECnet/IPX but let's discuss it.
>>>> Any ideas here?
>>>
>>> All these protocols should be handled one way or another someday. ;)
>>>
>>>
>>>>
>>>>>
>>>>>       I'm mentioning these more obscure protocols, because I doubt that
>>>>>       Landlock will grow more sophisticated support for them anytime soon,
>>>>>       so maybe the best option would be to just make it possible to
>>>>>       disable these?  Is that also part of the plan?
>>>>>
>>>>>       (I think there would be a lot of value in restricting network
>>>>>       access, even when it's done very broadly.  There are many programs
>>>>>       that don't need network at all, and among those that do need
>>>>>       network, most only require IP networking.
>>>
>>> Indeed, protocols that nobody care to make Landlock supports them will
>>> probably not have fine-grained control. We could extend the ruleset
>>> attributes to disable the use (i.e. not only the creation of new related
>>> sockets/resources) of network protocol families, in a way that would
>>> make sandboxes simulate a kernel without such protocol support. In this
>>> case, this should be an allowed list of protocols, and everything not in
>>> that list should be denied. This approach could be used for other kernel
>>> features (unrelated to network).
>>>
>>>
>>>>>
>>>>>       Btw, the argument for more broad disabling of network access was
>>>>>       already made at https://cr.yp.to/unix/disablenetwork.html in the
>>>>>       past.)
>>>
>>> This is interesting but scoped to a single use case. As specified at the
>>> beginning of this linked page, there must be exceptions, not only with
>>> AF_UNIX but also for (the newer) AF_VSOCK, and probably future ones.
>>> This is why I don't think a binary approach is a good one for Linux.
>>> Users should be able to specify what they need, and block the rest.
>>
>> Here is a design to be able to only allow a set of network protocols and
>> deny everything else. This would be complementary to Konstantin's patch
>> series which addresses fine-grained access control.
>>
>> First, I want to remind that Landlock follows an allowed list approach
>> with a set of (growing) supported actions (for compatibility reasons),
>> which is kind of an allow-list-on-a-deny-list. But with this proposal,
>> we want to be able to deny everything, which means: supported, not
>> supported, known and unknown protocols.
>>
> I think this makes sense.  ChomeOS can use it at the process level:
> disable network, allow VSOCK only, allow TCP only, etc.
> 
>> We could add a new "handled_access_socket" field to the landlock_ruleset
>> struct, which could contain a LANDLOCK_ACCESS_SOCKET_CREATE flag.
>>
>> If this field is set, users could add a new type of rules:
>> struct landlock_socket_attr {
>>       __u64 allowed_access;
>>       int domain; // see socket(2)

I guess "family" would also make sense. It's the name used in the 
kernel, the "AF" prefixes, and address_families(7). I'm not sure why 
"domain" was chosen for socket(2).


>>       int type; // see socket(2)
>> }
>>
> Do you want to add "int protocol" ? which is the third parameter of socket(2)
> According to protocols(5), the protocols are defined in:
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
> 
> It is part of IPv4/IPV6 header:
> https://www.rfc-editor.org/rfc/rfc791.html#section-3.1
> https://www.rfc-editor.org/rfc/rfc8200.html#section-3

I understand the rationale but I'm not sure if this would be useful. Do 
you have use cases?


> 
>> The allowed_access field would only contain
>> LANDLOCK_ACCESS_SOCKET_CREATE at first, but it could grow with other
>> actions (which cannot be handled with seccomp):
>> - use: walk through all opened FDs and mark them as allowed or denied
>> - receive: hook on received FDs
>> - send: hook on sent FDs
>>
> also bind, connect, accept.

I don't think "accept" would be useful, and I'm not sure if "bind" and 
"connect" would not be redundant with LANDLOCK_ACCESS_NET_{CONNECT,BIND}_TCP
Bind and connect for a datagram socket is optional, so this might lead 
to a false sense of security. If we want to support protocols other than 
TCP to restrict bind/connect, then they deserve to be controlled 
according to a port (or similar).

> 
>> We might also use the same approach for non-socket objects that can be
>> identified with some meaningful properties.
>>
>> What do you think?
> 
> -Jeff