linux-kernel - Re: [PATCH v4 11/30] landlock: Align partial refer access checks with final ones

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250110.igh2Cor3ahng@digikod.net>
Date: Fri, 10 Jan 2025 12:24:13 +0100
From: Mickaël Salaün <mic@...ikod.net>
To: Eric Paris <eparis@...hat.com>, Paul Moore <paul@...l-moore.com>, 
	Günther Noack <gnoack@...gle.com>, "Serge E . Hallyn" <serge@...lyn.com>
Cc: Ben Scarlato <akhna@...gle.com>, 
	Casey Schaufler <casey@...aufler-ca.com>, Charles Zaffery <czaffery@...lox.com>, 
	Daniel Burgener <dburgener@...ux.microsoft.com>, Francis Laniel <flaniel@...ux.microsoft.com>, 
	James Morris <jmorris@...ei.org>, Jann Horn <jannh@...gle.com>, Jeff Xu <jeffxu@...gle.com>, 
	Jorge Lucangeli Obes <jorgelo@...gle.com>, Kees Cook <kees@...nel.org>, 
	Konstantin Meskhidze <konstantin.meskhidze@...wei.com>, Matt Bobrowski <mattbobrowski@...gle.com>, 
	Mikhail Ivanov <ivanov.mikhail1@...wei-partners.com>, Phil Sutter <phil@....cc>, 
	Praveen K Paladugu <prapal@...ux.microsoft.com>, Robert Salvet <robert.salvet@...lox.com>, 
	Shervin Oloumi <enlightened@...gle.com>, Song Liu <song@...nel.org>, 
	Tahera Fahimi <fahimitahera@...il.com>, Tyler Hicks <code@...icks.com>, audit@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH v4 11/30] landlock: Align partial refer access checks
 with final ones

On Wed, Jan 08, 2025 at 04:43:19PM +0100, Mickaël Salaün wrote:
> Fix a logical issue that could have been visible if the source or the
> destination of a rename/link action was allowed for either the source or
> the destination but not both.  However, this logical bug is unreachable
> because either:
> - the rename/link action is allowed by the access rights tied to the
>   same mount point (without relying on access rights in a parent mount
>   point) and the access request is allowed (i.e. allow_parent1 and
>   allow_parent2 are true in current_check_refer_path),
> - or a common rule in a parent mount point updates the access check for
>   the source and the destination (cf. is_access_to_paths_allowed).
> 
> See the following layout1.refer_part_mount_tree_is_allowed test that
> work with and without this fix.
> 
> This fix does not impact current code but it is required for the audit
> support.
> 
> Cc: Günther Noack <gnoack@...gle.com>
> Signed-off-by: Mickaël Salaün <mic@...ikod.net>
> Link: https://lore.kernel.org/r/20250108154338.1129069-12-mic@digikod.net

Pushed in my next tree to simplify next patch series.

> ---
> 
> Changes since v2:
> - New patch.
> ---
>  security/landlock/fs.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> index 171012efb559..ddadc465581e 100644
> --- a/security/landlock/fs.c
> +++ b/security/landlock/fs.c
> @@ -567,6 +567,12 @@ static void test_no_more_access(struct kunit *const test)
>  #undef NMA_TRUE
>  #undef NMA_FALSE
>  
> +static bool is_layer_masks_allowed(
> +	layer_mask_t (*const layer_masks)[LANDLOCK_NUM_ACCESS_FS])
> +{
> +	return !memchr_inv(layer_masks, 0, sizeof(*layer_masks));
> +}
> +
>  /*
>   * Removes @layer_masks accesses that are not requested.
>   *
> @@ -584,7 +590,8 @@ scope_to_request(const access_mask_t access_request,
>  
>  	for_each_clear_bit(access_bit, &access_req, ARRAY_SIZE(*layer_masks))
>  		(*layer_masks)[access_bit] = 0;
> -	return !memchr_inv(layer_masks, 0, sizeof(*layer_masks));
> +
> +	return is_layer_masks_allowed(layer_masks);
>  }
>  
>  #ifdef CONFIG_SECURITY_LANDLOCK_KUNIT_TEST
> @@ -773,9 +780,14 @@ static bool is_access_to_paths_allowed(
>  	if (WARN_ON_ONCE(domain->num_layers < 1 || !layer_masks_parent1))
>  		return false;
>  
> +	allowed_parent1 = is_layer_masks_allowed(layer_masks_parent1);
> +
>  	if (unlikely(layer_masks_parent2)) {
>  		if (WARN_ON_ONCE(!dentry_child1))
>  			return false;
> +
> +		allowed_parent2 = is_layer_masks_allowed(layer_masks_parent2);
> +
>  		/*
>  		 * For a double request, first check for potential privilege
>  		 * escalation by looking at domain handled accesses (which are
> -- 
> 2.47.1
> 
>