From: Jeff Xu <jeffxu@chromium.org>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: "Konstantin Meskhidze (A)" <konstantin.meskhidze@huawei.com>,
"Günther Noack" <gnoack3000@gmail.com>,
willemdebruijn.kernel@gmail.com,
linux-security-module@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, yusongping@huawei.com,
artem.kuzin@huawei.com, "Jeff Xu" <jeffxu@google.com>,
"Jorge Lucangeli Obes" <jorgelo@chromium.org>,
"Allen Webb" <allenwebb@google.com>,
"Dmitry Torokhov" <dtor@google.com>
Subject: Re: [PATCH v9 00/12] Network support for Landlock - allowed list of protocols
Date: Wed, 28 Jun 2023 14:56:48 -0700 [thread overview]
Message-ID: <CABi2SkVWU=Wxb2y3fP702twyHBD3kVoySPGSz2X22VckvcHeXw@mail.gmail.com> (raw)
In-Reply-To: <a6318388-e28a-e96f-b1ae-51948c13de4d@digikod.net>
On Wed, Jun 28, 2023 at 12:03 PM Mickaël Salaün <mic@digikod.net> wrote:
>
>
> On 28/06/2023 04:33, Jeff Xu wrote:
> > On Mon, Jun 26, 2023 at 8:29 AM Mickaël Salaün <mic@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).
>
Agree also.
>
> >> 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?
>
I agree this field is not commonly used, so might not be that useful.
In most cases, the protocol field will just be 0.
One case I thought of previously is building an icmp or DHCP packet
with raw socket, but now I'm not sure what kind of support/enforce
the kernel has for the protocol field with raw socket.
We can drop this for now, if there is a clearer requirement in future,
it is easy to add a new rule.
>
> >
> >> 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
next prev parent reply other threads:[~2023-06-28 21:57 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 8:58 [PATCH v9 00/12] Network support for Landlock Konstantin Meskhidze
2023-01-16 8:58 ` [PATCH v9 01/12] landlock: Make ruleset's access masks more generic Konstantin Meskhidze
2023-01-16 8:58 ` [PATCH v9 02/12] landlock: Allow filesystem layout changes for domains without such rule type Konstantin Meskhidze
2023-02-10 17:34 ` Mickaël Salaün
2023-02-14 8:51 ` Konstantin Meskhidze (A)
2023-02-14 12:07 ` Mickaël Salaün
2023-02-14 12:57 ` Konstantin Meskhidze (A)
2023-01-16 8:58 ` [PATCH v9 03/12] landlock: Refactor landlock_find_rule/insert_rule Konstantin Meskhidze
2023-02-10 17:36 ` Mickaël Salaün
2023-02-14 10:15 ` Konstantin Meskhidze (A)
2023-02-14 12:09 ` Mickaël Salaün
2023-02-14 13:28 ` Konstantin Meskhidze (A)
2023-01-16 8:58 ` [PATCH v9 04/12] landlock: Refactor merge/inherit_ruleset functions Konstantin Meskhidze
2023-01-16 8:58 ` [PATCH v9 05/12] landlock: Move and rename umask_layers() and init_layer_masks() Konstantin Meskhidze
2023-02-10 17:37 ` Mickaël Salaün
2023-02-14 10:15 ` Konstantin Meskhidze (A)
2023-01-16 8:58 ` [PATCH v9 06/12] landlock: Refactor _unmask_layers() and _init_layer_masks() Konstantin Meskhidze
2023-02-10 17:38 ` Mickaël Salaün
2023-02-14 10:16 ` Konstantin Meskhidze (A)
2023-02-21 18:07 ` Mickaël Salaün
2023-03-06 7:52 ` Konstantin Meskhidze (A)
2023-01-16 8:58 ` [PATCH v9 07/12] landlock: Refactor landlock_add_rule() syscall Konstantin Meskhidze
2023-02-10 17:38 ` Mickaël Salaün
2023-02-14 10:18 ` Konstantin Meskhidze (A)
2023-01-16 8:58 ` [PATCH v9 08/12] landlock: Add network rules and TCP hooks support Konstantin Meskhidze
2023-02-10 17:39 ` Mickaël Salaün
2023-02-14 10:19 ` Konstantin Meskhidze (A)
2023-03-13 9:33 ` Konstantin Meskhidze (A)
2023-03-14 12:13 ` Mickaël Salaün
2023-03-14 14:38 ` Konstantin Meskhidze (A)
2023-02-21 18:04 ` Mickaël Salaün
2023-03-06 10:18 ` Konstantin Meskhidze (A)
2023-01-16 8:58 ` [PATCH v9 09/12] selftests/landlock: Share enforce_ruleset() Konstantin Meskhidze
2023-01-16 8:58 ` [PATCH v9 10/12] selftests/landlock: Add 10 new test suites dedicated to network Konstantin Meskhidze
2023-02-10 17:40 ` Mickaël Salaün
2023-02-14 10:36 ` Konstantin Meskhidze (A)
2023-02-14 12:13 ` Mickaël Salaün
2023-02-14 13:28 ` Konstantin Meskhidze (A)
2023-02-21 18:05 ` Mickaël Salaün
2023-03-06 12:03 ` Konstantin Meskhidze (A)
2023-03-06 16:00 ` Mickaël Salaün
2023-03-06 18:13 ` Konstantin Meskhidze (A)
2023-01-16 8:58 ` [PATCH v9 11/12] samples/landlock: Add network demo Konstantin Meskhidze
2023-01-16 8:58 ` [PATCH v9 12/12] landlock: Document Landlock's network support Konstantin Meskhidze
2023-01-21 23:07 ` Günther Noack
2023-01-23 9:38 ` Konstantin Meskhidze (A)
2023-01-27 18:22 ` Mickaël Salaün
2023-01-30 10:03 ` Konstantin Meskhidze (A)
2023-02-21 16:16 ` Mickaël Salaün
2023-03-06 13:43 ` Konstantin Meskhidze (A)
2023-03-06 16:09 ` Mickaël Salaün
2023-03-06 17:55 ` Konstantin Meskhidze (A)
2023-01-30 12:26 ` Konstantin Meskhidze (A)
2023-02-23 22:17 ` [PATCH v9 00/12] Network support for Landlock Günther Noack
2023-03-06 7:45 ` Konstantin Meskhidze (A)
2023-03-13 17:16 ` Konstantin Meskhidze (A)
2023-03-14 13:28 ` Mickaël Salaün
2023-06-26 15:29 ` [PATCH v9 00/12] Network support for Landlock - allowed list of protocols Mickaël Salaün
2023-06-28 2:33 ` Jeff Xu
2023-06-28 19:03 ` Mickaël Salaün
2023-06-28 21:56 ` Jeff Xu [this message]
2023-06-28 8:44 ` Günther Noack
2023-06-28 17:03 ` Jeff Xu
2023-06-28 19:29 ` Mickaël Salaün
2023-06-29 3:18 ` Jeff Xu
2023-06-29 11:07 ` Mickaël Salaün
2023-06-30 4:18 ` Jeff Xu
2023-06-30 18:23 ` Mickaël Salaün
2023-07-05 15:00 ` Jeff Xu
2023-07-12 11:30 ` Mickaël Salaün
2023-07-13 13:20 ` Konstantin Meskhidze (A)
2023-07-13 14:52 ` Mickaël Salaün
2023-07-13 11:44 ` Konstantin Meskhidze (A)
2023-06-28 19:07 ` Mickaël Salaün
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABi2SkVWU=Wxb2y3fP702twyHBD3kVoySPGSz2X22VckvcHeXw@mail.gmail.com' \
--to=jeffxu@chromium.org \
--cc=allenwebb@google.com \
--cc=artem.kuzin@huawei.com \
--cc=dtor@google.com \
--cc=gnoack3000@gmail.com \
--cc=jeffxu@google.com \
--cc=jorgelo@chromium.org \
--cc=konstantin.meskhidze@huawei.com \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
--cc=yusongping@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).