From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 1618B23C9; Sat, 1 Mar 2025 02:19:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740795560; cv=none; b=Pn5i6YivB0B/o4xAE2eNNA4xgCkuUW25iTHD+/IVY8SKZDjTDQ8aBWoKk+WAnJyW5l/uUcLEDuBnRXHPL87dCchL7FcKOeK/6OFK1YPdWhspuD9EMe1Ud7YO5Eqi2iUML3G8wlW9w3PX4RxK+OAjkZBYduaE8i2GxW3isua7cvQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740795560; c=relaxed/simple; bh=cP5LLog8QYA15qY6G6z2j9WolFBDsu0s1MuFuS0Od1U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AbeloH+ly+664/H0SJXBUmnGKrbDWJoYh8ANSuCry2MEKfC8b5eoIdbkfKEo8seuUHKm1V3om2aZ9krMbT/yX5WE7WObvU8dNdt+qV/ZVFG/Nk3oivREYkZpxU/l6QeaugM3ZV2JbG3/kCURYZSD8YUcR4e+kTTCHORRzD8IPfQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lJtj7E+Z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lJtj7E+Z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 070F4C4CED6; Sat, 1 Mar 2025 02:19:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740795559; bh=cP5LLog8QYA15qY6G6z2j9WolFBDsu0s1MuFuS0Od1U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lJtj7E+Zts7tOwSbKzDGEguy9UOLMYZuKzFeX2/0wKbthGoAS2N3WemoJepw3toZW Ghhjd1rdocrVUN4Ege5O3soyBGLjJIKxw3fVYs39er7ZuhONeFTbd7Pw2iCGOP4+QM jWhc9aLCWc0l3tCEGNC0LaB28WMNOUOkr1rReITa4rblDx5gqlEubfwxybJvIcDPuf 38gBeOvXLOBNPi/RSeUabN20wcIfjZNX+li6VypxtDUHFSwZNlvGGJ0Z9c3Zai2AwZ f2HnXVop7TycEbhDPALZUzUHM+YcLkP5ZBsO8nZwRB1ewctHThk6Dh3TMOs4kWnwhq 10AgW13Bu+iqg== Date: Sat, 1 Mar 2025 04:19:15 +0200 From: Jarkko Sakkinen To: Mimi Zohar Cc: Eric Snowberg , Paul Moore , David Howells , "open list:SECURITY SUBSYSTEM" , David Woodhouse , "herbert@gondor.apana.org.au" , "davem@davemloft.net" , Ard Biesheuvel , James Morris , "Serge E. Hallyn" , Roberto Sassu , Dmitry Kasatkin , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , "casey@schaufler-ca.com" , Stefan Berger , "ebiggers@kernel.org" , Randy Dunlap , open list , "keyrings@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-integrity@vger.kernel.org" Subject: Re: [RFC PATCH v3 00/13] Clavis LSM Message-ID: References: <20241017155516.2582369-1-eric.snowberg@oracle.com> <72F52F71-C7F3-402D-8441-3D636A093FE8@oracle.com> <506e8e58e5236a4525b18d84bafa9aae80b24452.camel@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-security-module@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: <506e8e58e5236a4525b18d84bafa9aae80b24452.camel@linux.ibm.com> On Thu, Feb 27, 2025 at 03:41:18PM -0500, Mimi Zohar wrote: > On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote: > > > > > On Jan 5, 2025, at 8:40 PM, Paul Moore wrote: > > > > > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore wrote: > > > > > > > > Regardless, back to Clavis ... reading quickly through the cover > > > > letter again, I do somewhat wonder if this isn't better integrated > > > > into the keyring proper; have you talked to both David and Jarkko > > > > about this? > > > > > > I realize I should probably expand on my thinking a bit, especially > > > since my comment a while regarding LSMs dedicated to enforcing access > > > control on keys is what was given as a reason for making Clavis a LSM. > > > > > > I still stand by my comment from over a year ago that I see no reason > > > why we couldn't support a LSM that enforces access controls on > > > keyrings/keys. What gives me pause with the Clavis LSM is that so > > > much of Clavis is resident in the keyrings themselves, e.g. Clavis > > > policy ACLs and authorization keys, that it really feels like it > > > should be part of the keys subsystem and not a LSM. Yes, existing > > > LSMs do have LSM specific data that resides outside of the LSM and in > > > an object's subsystem, but that is usually limited to security > > > identifiers and similar things, not the LSM's security policy. > > Hi Jarkko, David, > > Both Paul's and my main concerns with this patch set is storing policy in the > keyring. We would appreciate your chiming in here about storing key policy in > the keyring itself. Right so the problem here would be that keyring defines policy for keys? Like in abstract "textbook sense" a policy should not live within in the closure that it dictactes. And the most classic issue would be probably circular dependencies. Theory aside, in practical sense, can you spot an example from the patch set where we could introduce issue by having Clavis as it is? > > thanks, > > Mimi BR, Jarkko