From: "Mickaël Salaün" <mic@digikod.net>
To: "Konstantin Meskhidze (A)" <konstantin.meskhidze@huawei.com>
Cc: willemdebruijn.kernel@gmail.com, gnoack3000@gmail.com,
linux-security-module@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, yusongping@huawei.com,
artem.kuzin@huawei.com
Subject: Re: [PATCH v13 08/12] landlock: Add network rules and TCP hooks support
Date: Tue, 24 Oct 2023 11:03:52 +0200 [thread overview]
Message-ID: <20231024.Ahdeepoh7wos@digikod.net> (raw)
In-Reply-To: <ea02392e-4460-9695-050f-7519aecebec2@huawei.com>
On Tue, Oct 24, 2023 at 06:18:54AM +0300, Konstantin Meskhidze (A) wrote:
>
>
> 10/20/2023 12:49 PM, Mickaël Salaün пишет:
> > On Fri, Oct 20, 2023 at 07:08:33AM +0300, Konstantin Meskhidze (A) wrote:
> > >
> > >
> > > 10/18/2023 3:29 PM, Mickaël Salaün пишет:
> > > > On Mon, Oct 16, 2023 at 09:50:26AM +0800, Konstantin Meskhidze wrote:
> > > > > diff --git a/security/landlock/net.h b/security/landlock/net.h
> > > > > new file mode 100644
> > > > > index 000000000000..588a49fd6907
> > > > > --- /dev/null
> > > > > +++ b/security/landlock/net.h
> > > > > @@ -0,0 +1,33 @@
> > > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > > +/*
> > > > > + * Landlock LSM - Network management and hooks
> > > > > + *
> > > > > + * Copyright © 2022-2023 Huawei Tech. Co., Ltd.
> > > > > + */
> > > > > +
> > > > > +#ifndef _SECURITY_LANDLOCK_NET_H
> > > > > +#define _SECURITY_LANDLOCK_NET_H
> > > > > +
> > > > > +#include "common.h"
> > > > > +#include "ruleset.h"
> > > > > +#include "setup.h"
> > > > > +
> > > > > +#if IS_ENABLED(CONFIG_INET)
> > > > > +__init void landlock_add_net_hooks(void);
> > > > > +
> > > > > +int landlock_append_net_rule(struct landlock_ruleset *const ruleset,
> > > > > + const u16 port, access_mask_t access_rights);
> > > > > +#else /* IS_ENABLED(CONFIG_INET) */
> > > > > +static inline void landlock_add_net_hooks(void)
> > > > > +{
> > > > > +}
> > > > > +
> > > > > +static inline int
> > > > > +landlock_append_net_rule(struct landlock_ruleset *const ruleset, const u16 port,
> > > > > + access_mask_t access_rights);
> > > > > +{
> > > > > + return -EAFNOSUPPORT;
> > > > > +}
> > > > > +#endif /* IS_ENABLED(CONFIG_INET) */
> > > > > +
> > > > > +#endif /* _SECURITY_LANDLOCK_NET_H */
> > > > > diff --git a/security/landlock/ruleset.c b/security/landlock/ruleset.c
> > > > > index 4c209acee01e..1fe4298ff4a7 100644
> > > > > --- a/security/landlock/ruleset.c
> > > > > +++ b/security/landlock/ruleset.c
> > > > > @@ -36,6 +36,11 @@ static struct landlock_ruleset *create_ruleset(const u32 num_layers)
> > > > > refcount_set(&new_ruleset->usage, 1);
> > > > > mutex_init(&new_ruleset->lock);
> > > > > new_ruleset->root_inode = RB_ROOT;
> > > > > +
> > > > > +#if IS_ENABLED(CONFIG_INET)
> > > > > + new_ruleset->root_net_port = RB_ROOT;
> > > > > +#endif /* IS_ENABLED(CONFIG_INET) */
> > > > > +
> > > > > new_ruleset->num_layers = num_layers;
> > > > > /*
> > > > > * hierarchy = NULL
> > > > > @@ -46,16 +51,21 @@ static struct landlock_ruleset *create_ruleset(const u32 num_layers)
> > > > > }
> > > > > > > struct landlock_ruleset *
> > > > > -landlock_create_ruleset(const access_mask_t fs_access_mask)
> > > > > +landlock_create_ruleset(const access_mask_t fs_access_mask,
> > > > > + const access_mask_t net_access_mask)
> > > > > {
> > > > > struct landlock_ruleset *new_ruleset;
> > > > > > > /* Informs about useless ruleset. */
> > > > > - if (!fs_access_mask)
> > > > > + if (!fs_access_mask && !net_access_mask)
> > > > > return ERR_PTR(-ENOMSG);
> > > > > new_ruleset = create_ruleset(1);
> > > > > - if (!IS_ERR(new_ruleset))
> > > > > + if (IS_ERR(new_ruleset))
> > > > > + return new_ruleset;
> > > > > + if (fs_access_mask)
> > > > > landlock_add_fs_access_mask(new_ruleset, fs_access_mask, 0);
> > > > > + if (net_access_mask)
> > > > > + landlock_add_net_access_mask(new_ruleset, net_access_mask, 0);
> > > > > This is good, but it is not tested: we need to add a test that
> > > both
> > > > handle FS and net restrictions. You can add one in net.c, just handling
> > > > LANDLOCK_ACCESS_FS_READ_DIR and LANDLOCK_ACCESS_NET_BIND_TCP, add one
> > > > rule with path_beneath (e.g. /dev) and another with net_port, and check
> > > > that open("/") is denied, open("/dev") is allowed, and and only the
> > > > allowed port is allowed with bind(). This test should be simple and can
> > > > only check against an IPv4 socket, i.e. using ipv4_tcp fixture, just
> > > > after port_endianness. fcntl.h should then be included by net.c
> > >
> > > Ok.
> > > > > I guess that was the purpose of layout1.with_net (in fs_test.c)
> > > but it
> > >
> > > Yep. I added this kind of nest in fs_test.c to test both fs and network
> > > rules together.
> > > > is not complete. You can revamp this test and move it to net.c
> > > > following the above suggestions, keeping it consistent with other tests
> > > > in net.c . You don't need the test_open() nor create_ruleset() helpers.
> > > > > This test must failed if we change
> > > "ruleset->access_masks[layer_level] |="
> > > > to "ruleset->access_masks[layer_level] =" in
> > > > landlock_add_fs_access_mask() or landlock_add_net_access_mask().
> > >
> > > Do you want to change it? Why?
> >
> > The kernel code is correct and must not be changed. However, if by
> > mistake we change it and remove the OR, a test should catch that. We
> > need a test to assert this assumption.
> >
> > > Fs and network masks are ORed to not intersect with each other.
> >
> > Yes, they are ORed, and we need a test to check that. Noting is
> > currently testing this OR (and the different rule type consistency).
> > I'm suggesting to revamp the layout1.with_net test into
> > ipv4_tcp.with_fs and make it check ruleset->access_masks[] and rule
> > addition of different types.
From the other email:
> Thinking about this test. We don't need to add any additional ASSERT here.
> Anyway if we accidentally change "ruleset->access_masks[layer_level] |=" to
> "ruleset->access_masks[layer_level] =" we will fail either in opening
> directory or in port binding, cause adding a second rule (fs or net) will
> overwrite a first one's mask. it does not matter which one goes first. I
> will check it and send you a message.
> What do you think?
>
> About my previous comment.
>
> Checking the code we can notice that adding fs mask goes first:
>
> ...
> if (fs_access_mask)
> landlock_add_fs_access_mask(new_ruleset, fs_access_mask, 0);
> if (net_access_mask)
> landlock_add_net_access_mask(new_ruleset, net_access_mask, 0);
> ....
>
> So with we change "ruleset->access_masks[layer_level] |="
> >> > to "ruleset->access_masks[layer_level] =" in
> landlock_add_fs_access_mask() nothing bad will happen.
> But if we do that in landlock_add_net_access_mask()
> fs mask will be overwritten and adding fs rule will fail
> (as unhandled allowed_accesss).
Right. What is the conclusion here? Are you OK with my test proposal?
next prev parent reply other threads:[~2023-10-24 9:04 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-16 1:50 [PATCH v13 00/12] Network support for Landlock Konstantin Meskhidze
2023-10-16 1:50 ` [PATCH v13 01/12] landlock: Make ruleset's access masks more generic Konstantin Meskhidze
2023-10-18 12:28 ` Mickaël Salaün
2023-10-19 1:45 ` Konstantin Meskhidze (A)
2023-10-16 1:50 ` [PATCH v13 02/12] landlock: Allow FS topology changes for domains without such rule type Konstantin Meskhidze
2023-10-16 1:50 ` [PATCH v13 03/12] landlock: Refactor landlock_find_rule/insert_rule Konstantin Meskhidze
2023-10-16 1:50 ` [PATCH v13 04/12] landlock: Refactor merge/inherit_ruleset functions Konstantin Meskhidze
2023-10-16 1:50 ` [PATCH v13 05/12] landlock: Move and rename layer helpers Konstantin Meskhidze
2023-10-16 1:50 ` [PATCH v13 06/12] landlock: Refactor " Konstantin Meskhidze
2023-10-16 1:50 ` [PATCH v13 07/12] landlock: Refactor landlock_add_rule() syscall Konstantin Meskhidze
2023-10-18 12:28 ` Mickaël Salaün
2023-10-19 11:59 ` Konstantin Meskhidze (A)
2023-10-18 16:34 ` Mickaël Salaün
2023-10-19 11:57 ` Konstantin Meskhidze (A)
2023-10-16 1:50 ` [PATCH v13 08/12] landlock: Add network rules and TCP hooks support Konstantin Meskhidze
2023-10-18 12:29 ` Mickaël Salaün
2023-10-20 4:08 ` Konstantin Meskhidze (A)
2023-10-20 9:49 ` Mickaël Salaün
2023-10-20 11:58 ` Konstantin Meskhidze (A)
2023-10-20 15:41 ` Mickaël Salaün
2023-10-23 7:23 ` Konstantin Meskhidze (A)
2023-10-23 8:30 ` Mickaël Salaün
2023-10-23 8:56 ` Konstantin Meskhidze (A)
2023-10-24 2:51 ` Konstantin Meskhidze (A)
2023-10-24 3:18 ` Konstantin Meskhidze (A)
2023-10-24 9:03 ` Mickaël Salaün [this message]
2023-10-24 9:12 ` Konstantin Meskhidze (A)
2023-10-25 11:29 ` Mickaël Salaün
2023-10-26 2:02 ` Konstantin Meskhidze (A)
2023-10-18 16:34 ` Mickaël Salaün
2023-10-20 9:40 ` Konstantin Meskhidze (A)
2023-10-16 1:50 ` [PATCH v13 09/12] selftests/landlock: Share enforce_ruleset() Konstantin Meskhidze
2023-10-16 1:50 ` [PATCH v13 10/12] selftests/landlock: Add 7 new test variants dedicated to network Konstantin Meskhidze
2023-10-18 12:32 ` Mickaël Salaün
2023-10-20 11:41 ` Konstantin Meskhidze (A)
2023-10-20 15:40 ` Mickaël Salaün
2023-10-23 7:09 ` Konstantin Meskhidze (A)
2023-10-23 8:44 ` Mickaël Salaün
2023-10-23 9:15 ` Konstantin Meskhidze (A)
2023-10-16 1:50 ` [PATCH v13 11/12] samples/landlock: Add network demo Konstantin Meskhidze
2023-10-18 12:33 ` Mickaël Salaün
2023-10-20 11:59 ` Konstantin Meskhidze (A)
2023-10-16 1:50 ` [PATCH v13 12/12] landlock: Document Landlock's network support Konstantin Meskhidze
2023-10-18 12:34 ` Mickaël Salaün
2023-10-20 12:17 ` Konstantin Meskhidze (A)
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=20231024.Ahdeepoh7wos@digikod.net \
--to=mic@digikod.net \
--cc=artem.kuzin@huawei.com \
--cc=gnoack3000@gmail.com \
--cc=konstantin.meskhidze@huawei.com \
--cc=linux-security-module@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.