Date: Mon, 26 Jun 2023 17:29:34 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: "Konstantin Meskhidze (A)" <konstantin.meskhidze@...wei.com>,
 Günther Noack <gnoack3000@...il.com>
Cc: willemdebruijn.kernel@...il.com, linux-security-module@...r.kernel.org,
 netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
 yusongping@...wei.com, artem.kuzin@...wei.com, Jeff Xu <jeffxu@...gle.com>,
 Jorge Lucangeli Obes <jorgelo@...omium.org>,
 Allen Webb <allenwebb@...gle.com>, Dmitry Torokhov <dtor@...gle.com>
Subject: Re: [PATCH v9 00/12] Network support for Landlock - allowed list of
 protocols

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.

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)
     int type; // see socket(2)
}

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

We might also use the same approach for non-socket objects that can be 
identified with some meaningful properties.

What do you think?

Powered by blists - more mailing lists