From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-42a8.mail.infomaniak.ch (smtp-42a8.mail.infomaniak.ch [84.16.66.168]) (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 DE45720C013 for ; Fri, 10 Jan 2025 11:24:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=84.16.66.168 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736508259; cv=none; b=QMePK+nW0pJYg66v8z9heCeSLAYyA+hsdHVOrjrHZtD8KTkEtbrDxKNPUk4HYtLcS7IiLjVKR57c8QFlorgnVwCD2gELAQllf2Mpw5/HFI46qJLgguYg6l6xxsRiKco/S+Fc3Nk7GcPCKeQQi/wUr4yU3yiktunhs/jwLhTi3S0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736508259; c=relaxed/simple; bh=0ofzsNBeJwsceqHy80qxVNumuzBRVawm1s2qo6K045E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aVfs/yTsp3dtJNfL8I4BVcCT14SlVndA5KXXnYAvmFzGWwVEkTCH0Ykjw1PHKqYg7TtQuuE2iBvnH0XG3HGeZZ7+NgbGIKM6JYf8hzo6ZoVw5oKcx6btAlWJEKiHQmrIeExP5O72yIwVX06VaThU/WF4ZUWyEepqe1FprufNawY= 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=OfjVX/00; arc=none smtp.client-ip=84.16.66.168 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="OfjVX/00" Received: from smtp-3-0000.mail.infomaniak.ch (smtp-3-0000.mail.infomaniak.ch [10.4.36.107]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4YTznW0DglzbQq; Fri, 10 Jan 2025 12:24:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1736508254; bh=hsqoIUmFQ8PGR8DlEAvfzOpwE0yufLTkSbhiASC8chM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OfjVX/00mDbJqugIYn52ue0YCPoQk9bBTdyiL1vIRgmZadghf/m5wjQMdiKuircri D4KK65r6gFXmyxL5uXzyLOZarfc0CDOEW8FlvcVW1Xe5gQx4DsG5GCeSQZ5DqedCZE bTX+/QmmzeDuugyAwh+1YSLIrdSmArtgqeuyX63E= Received: from unknown by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4YTznT4yggzLpM; Fri, 10 Jan 2025 12:24:13 +0100 (CET) Date: Fri, 10 Jan 2025 12:24:13 +0100 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Eric Paris , Paul Moore , =?utf-8?Q?G=C3=BCnther?= Noack , "Serge E . Hallyn" Cc: 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: Re: [PATCH v4 11/30] landlock: Align partial refer access checks with final ones Message-ID: <20250110.igh2Cor3ahng@digikod.net> References: <20250108154338.1129069-1-mic@digikod.net> <20250108154338.1129069-12-mic@digikod.net> Precedence: bulk X-Mailing-List: audit@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250108154338.1129069-12-mic@digikod.net> X-Infomaniak-Routing: alpha 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 > Signed-off-by: Mickaël Salaün > 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 > >