Message-ID: <CABi2SkXgTv8Bz62hwkymz2msvNXZQUWM1acT-_Lcq2=Mb-BD6w@mail.gmail.com>
Date: Tue, 27 Jun 2023 19:33:14 -0700
From: Jeff Xu <jeffxu@...omium.org>
To: Mickaël Salaün <mic@...ikod.net>
Cc: "Konstantin Meskhidze (A)" <konstantin.meskhidze@...wei.com>, 
	Günther Noack <gnoack3000@...il.com>, 
	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

On Mon, Jun 26, 2023 at 8:29 AM Mickaël Salaün <mic@...ikod.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)
>      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

> 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.

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

-Jeff

Powered by blists - more mailing lists