From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E71C2C46CA1 for ; Wed, 18 Oct 2023 14:17:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345055AbjJRORv (ORCPT ); Wed, 18 Oct 2023 10:17:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344973AbjJROR3 (ORCPT ); Wed, 18 Oct 2023 10:17:29 -0400 Received: from smtp-190e.mail.infomaniak.ch (smtp-190e.mail.infomaniak.ch [IPv6:2001:1600:4:17::190e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B78C10EF for ; Wed, 18 Oct 2023 07:14:11 -0700 (PDT) Received: from smtp-2-0001.mail.infomaniak.ch (unknown [10.5.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4S9Xs95kx0zMqBDW; Wed, 18 Oct 2023 14:14:05 +0000 (UTC) Received: from unknown by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4S9Xs900CdzMppKm; Wed, 18 Oct 2023 16:14:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digikod.net; s=20191114; t=1697638445; bh=AJCppQD+bLjbEs7xewzXV45Zcp0SfH1Bhh+lWslfscM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n23hMfMY7BCeeWfC+vRX7uYp3N2pqK1TOOIKiCpU1sWaX5L85cu8QOJvf3HhcUjx0 72e2daim6t3sKxX3Bjj93peawurco7/d809Ro3jVgn5rsGowPdzmA2GWt7hsyOmib4 aVsI6v+B2mIOSlnfQgc3KKNanxmjtBWB5Sy7YNR0= Date: Wed, 18 Oct 2023 16:14:03 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Eric Snowberg Cc: Paul Moore , Mimi Zohar , "Serge E. Hallyn" , Jarkko Sakkinen , David Howells , David Woodhouse , Kanth Ghatraju , Konrad Wilk , "linux-integrity@vger.kernel.org" , "keyrings@vger.kernel.org" , open list , linux-security-module Subject: Re: RFC: New LSM to control usage of x509 certificates Message-ID: <20231018.heiju2Shexai@digikod.net> References: <20230914.shah5al9Kaib@digikod.net> <20231005.dajohf2peiBu@digikod.net> <5c795b4cf6d7460af205e85a36194fa188136c38.camel@linux.ibm.com> <2512D2AE-4ACA-41B9-B9FB-C2B4802B9A10@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2512D2AE-4ACA-41B9-B9FB-C2B4802B9A10@oracle.com> X-Infomaniak-Routing: alpha Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 17, 2023 at 07:34:25PM +0000, Eric Snowberg wrote: > > > > On Oct 17, 2023, at 12:51 PM, Paul Moore wrote: > > > > On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar wrote: > >> On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote: > >>> On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar wrote: > >>>> On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote: > >>>>> On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar wrote: > >>>>>> On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote: > >>>>>>>>>> A complementary approach would be to create an > >>>>>>>>>> LSM (or a dedicated interface) to tie certificate properties to a set of > >>>>>>>>>> kernel usages, while still letting users configure these constraints. > >>>>>>>>> > >>>>>>>>> That is an interesting idea. Would the other security maintainers be in > >>>>>>>>> support of such an approach? Would a LSM be the correct interface? > >>>>>>>>> Some of the recent work I have done with introducing key usage and CA > >>>>>>>>> enforcement is difficult for a distro to pick up, since these changes can be > >>>>>>>>> viewed as a regression. Each end-user has different signing procedures > >>>>>>>>> and policies, so making something work for everyone is difficult. Letting the > >>>>>>>>> user configure these constraints would solve this problem. > >>>>>> > >>>>>> Something definitely needs to be done about controlling the usage of > >>>>>> x509 certificates. My concern is the level of granularity. Would this > >>>>>> be at the LSM hook level or even finer granaularity? > >>>>> > >>>>> You lost me, what do you mean by finer granularity than a LSM-based > >>>>> access control? Can you give an existing example in the Linux kernel > >>>>> of access control granularity that is finer grained than what is > >>>>> provided by the LSMs? > >>>> > >>>> The current x509 certificate access control granularity is at the > >>>> keyring level. Any key on the keyring may be used to verify a > >>>> signature. Finer granularity could associate a set of certificates on > >>>> a particular keyring with an LSM hook - kernel modules, BPRM, kexec, > >>>> firmware, etc. Even finer granularity could somehow limit a key's > >>>> signature verification to files in particular software package(s) for > >>>> example. > >>>> > >>>> Perhaps Mickaël and Eric were thinking about a new LSM to control usage > >>>> of x509 certificates from a totally different perspective. I'd like to > >>>> hear what they're thinking. > >>>> > >>>> I hope this addressed your questions. > >>> > >>> Okay, so you were talking about finer granularity when compared to the > >>> *current* LSM keyring hooks. Gotcha. > >>> > >>> If we need additional, or modified, hooks that shouldn't be a problem. > >>> Although I'm guessing the answer is going to be moving towards > >>> purpose/operation specific keyrings which might fit in well with the > >>> current keyring level controls. > >> > >> I don't believe defining per purpose/operation specific keyrings will > >> resolve the underlying problem of granularity. > > > > Perhaps not completely, but for in-kernel operations I believe it is > > an attractive idea. > > Could the X.509 Extended Key Usage (EKU) extension [1], be used here? > Various OIDs would need to be defined or assigned for each purpose. > Once assigned, the kernel could parse this information and do the > enforcement. Then all keys could continue to remain in the .builtin, > .secondary, and .machine keyrings. Only a subset of each keyring > would be used for verification based on what is contained in the EKU. > > 1. https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12 I was also thinking about this kind of use cases. Because it might be difficult in practice to control all certificate properties, we might want to let sysadmins configure these subset of keyring according to various certificate properties. There are currently LSM hooks to control interactions with kernel keys by user space, and keys are already tied to LSM blobs. New LSM hooks could be added to dynamically filter keyrings according to kernel usages (e.g. kernel module verification, a subset of an authentication mechanism according to the checked object).