linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Wed, 25 Oct 2023 13:29:24 +0200	[thread overview]
Message-ID: <20231025.ooG0Uach9aes@digikod.net> (raw)
In-Reply-To: <bc4699d7-ab54-a3b8-06a0-1724a63c6076@huawei.com>

On Tue, Oct 24, 2023 at 12:12:01PM +0300, Konstantin Meskhidze (A) wrote:
> 
> 
> 10/24/2023 12:03 PM, Mickaël Salaün пишет:
> > 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?
> 
>   So we just check if landlock_add_net_access_mask() would be changed by
> mistake?

With the current kernel code, yes.

> Changing landlock_add_fs_access_mask() does not break the logic. Am
> I correct here?

Yes, only landlock_add_net_access_mask() changes would be detected with
the current kernel code, but the test checks the whole semantic, so even
the following code with a buggy landlock_add_fs_access_mask() would be
detected:

if (net_access_mask)
	landlock_add_net_access_mask(new_ruleset, net_access_mask, 0);
if (fs_access_mask)
	landlock_add_fs_access_mask(new_ruleset, fs_access_mask, 0);

  reply	other threads:[~2023-10-25 11:29 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
2023-10-24  9:12             ` Konstantin Meskhidze (A)
2023-10-25 11:29               ` Mickaël Salaün [this message]
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=20231025.ooG0Uach9aes@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 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).