From nobody Fri Dec 19 19:19:25 2025 Received: from smtp-8fab.mail.infomaniak.ch (smtp-8fab.mail.infomaniak.ch [83.166.143.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5A52020100E for ; Wed, 8 Jan 2025 15:44:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=83.166.143.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736351052; cv=none; b=IxRL+Es/RLgeCcXxEJ4dGVmhOBTmUfznMhWLOQ5OC5YSflJjv7tSZpu6GMBr2pl7eJVqN/w3Q4w3jeSjTEMgWSdt2GwhYkqnUnnhm+8w9Tj/25Q1Ry0YTKVGekeNbU92mne+xqUQqt8vdGYXl8Sjp9zNP0p5jkS6AGdfQtuo7BU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736351052; c=relaxed/simple; bh=7ibfBYEi6f3gRg6pygE5JOGwb52bRToRkj9Kef1B8ek=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Cn71mOIDlaXL4uIzir8htYf8VJoU5QQV5vgv1l2CUg0sf4f1vmS+wxYrfKeD40zTEhw4UE+FEHysdWdenuj4Mm+8p+mpPQuq/nN+AAPM0gb4zhQIz9pJTLzu5W3qlVMwoWLUYKpWbsvBDUvRlY0ZEKydJWJZ3+ZeY7nySXUijW8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net; spf=pass smtp.mailfrom=digikod.net; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b=EE6astl+; arc=none smtp.client-ip=83.166.143.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=digikod.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b="EE6astl+" Received: from smtp-4-0000.mail.infomaniak.ch (smtp-4-0000.mail.infomaniak.ch [10.7.10.107]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4YSsfC2vR0zrLS; Wed, 8 Jan 2025 16:44:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1736351043; bh=St27lDxiIu3v5ST9RZRvjuRVlErWHof4RK6UwUhVE6s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EE6astl+NKDQZY4iKCq9GAxWqt3IG1EENFRkpE8H4fDeq6O/LM8chyhOGtDypQiPq d/hSPBLSQ9cJyWAPawwpK0HiukFyXm9zAHfl4hHdcaOfIbMxbmVGYDN2sFqhjkzChJ ayrLksfAHMq35lCSixBfhEwAFr4/7LitgPrcg73I= Received: from unknown by smtp-4-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4YSsfB4Ypyz2F3; Wed, 8 Jan 2025 16:44:02 +0100 (CET) From: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= To: Eric Paris , Paul Moore , =?UTF-8?q?G=C3=BCnther=20Noack?= , "Serge E . Hallyn" Cc: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= , Ben Scarlato , Casey Schaufler , Charles Zaffery , Daniel Burgener , Francis Laniel , James Morris , Jann Horn , Jeff Xu , Jorge Lucangeli Obes , Kees Cook , Konstantin Meskhidze , Matt Bobrowski , Mikhail Ivanov , Phil Sutter , Praveen K Paladugu , Robert Salvet , Shervin Oloumi , Song Liu , Tahera Fahimi , Tyler Hicks , audit@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: [PATCH v4 11/30] landlock: Align partial refer access checks with final ones Date: Wed, 8 Jan 2025 16:43:19 +0100 Message-ID: <20250108154338.1129069-12-mic@digikod.net> In-Reply-To: <20250108154338.1129069-1-mic@digikod.net> References: <20250108154338.1129069-1-mic@digikod.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Infomaniak-Routing: alpha 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=C3=BCnther Noack Signed-off-by: Micka=C3=ABl Sala=C3=BCn Link: https://lore.kernel.org/r/20250108154338.1129069-12-mic@digikod.net --- 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 te= st) #undef NMA_TRUE #undef NMA_FALSE =20 +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, =20 for_each_clear_bit(access_bit, &access_req, ARRAY_SIZE(*layer_masks)) (*layer_masks)[access_bit] =3D 0; - return !memchr_inv(layer_masks, 0, sizeof(*layer_masks)); + + return is_layer_masks_allowed(layer_masks); } =20 #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; =20 + allowed_parent1 =3D is_layer_masks_allowed(layer_masks_parent1); + if (unlikely(layer_masks_parent2)) { if (WARN_ON_ONCE(!dentry_child1)) return false; + + allowed_parent2 =3D 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 --=20 2.47.1