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 BD4D9CDB474 for ; Tue, 17 Oct 2023 17:29:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234991AbjJQR3X (ORCPT ); Tue, 17 Oct 2023 13:29:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234992AbjJQR3W (ORCPT ); Tue, 17 Oct 2023 13:29:22 -0400 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18306112 for ; Tue, 17 Oct 2023 10:29:18 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-d84f18e908aso6712988276.1 for ; Tue, 17 Oct 2023 10:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1697563758; x=1698168558; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=w1ro9HlJSCZOnQY3V+1VmfmbVpDBOi+uN5Fq4ETuRqg=; b=deAuIb4pEhjm6eBPy09V3tBAICS79bZ60HcDl2EaptWgOX65CHSTtunZZBxZywbUxc 7f/LQE141m184U03smIc9cArPvIvNYDioVqhTS+gfnVqBeUF9afNOp16zXYcDEeWe5vr EqdXfpM6LQWgrJhH0Tsl67FUAhZp26IVs6T3bMgKMU8V6wv9YGhB+rL36JPgLuYVYq73 petuYj48JGDAZMHz/6hXb4+5JgL7/m6oIlqO+QeoJrBUGJc4CMSPtDfyqOV6p62xxonx Iy7WCVQP07odKbIUI/GZKYzITHpkahyoCLxVvrjmQaxVKPWlBdM1IUcYIn/TbocVdrFe Gd+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697563758; x=1698168558; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=w1ro9HlJSCZOnQY3V+1VmfmbVpDBOi+uN5Fq4ETuRqg=; b=kERu2R/8WgrBrLam20ieU9TRO9I1WVysvvPIUdvebYhc7G+R6i+6U6zDxH0g4KtMXu DvthF1IjVamTdCmbMaypq2Hng6yKGyLZ4VYGAF+7UvEJW+o035G1ucabjbQbrJniK6rc wDoXydWUWY8iT2tJZWIm2MQye42p1+QeWqNskc+bH/mHPrgKYvveU/cKBbxUFhVfokK7 i4UpaO2Sq5pwXAG8sfJpPycFDhtRP8TmhdLo6LXtV/mtf5FE9qeVrIrqimVfjN/krJAs bTd96rDS1V+51njLPJGNZYw1a+SG+xtGz2MO4Rj8/yZTRmOx7AVo/LTCbJpTt+8g7nSJ oOhA== X-Gm-Message-State: AOJu0YwaWxSWWyjmklojoGx1XTaqyGuZ3v2YBLPO6CKGm3fhsiJ4THAG YUfuRqYPZA6FRokH7psws+R1xuggAYT1kULyJZMC X-Google-Smtp-Source: AGHT+IE20i63zTruAYA/HeKI6xRC7P5Iphgvp7RwIHUvJvGWCiFiihYJF7iPPrjTqS0EbJ0jsUao4v+7X57KlQGZQNY= X-Received: by 2002:a25:2383:0:b0:d9a:3bbb:8602 with SMTP id j125-20020a252383000000b00d9a3bbb8602mr2572828ybj.64.1697563757988; Tue, 17 Oct 2023 10:29:17 -0700 (PDT) MIME-Version: 1.0 References: <932231F5-8050-4436-84B8-D7708DC43845@oracle.com> <7335a4587233626a39ce9bc8a969957d7f43a34c.camel@linux.ibm.com> <1149b6dbfdaabef3e48dc2852cc76aa11a6dd6b0.camel@linux.ibm.com> <4A0505D0-2933-43BD-BEEA-94350BB22AE7@oracle.com> <20230913.Ceifae7ievei@digikod.net> <20230914.shah5al9Kaib@digikod.net> <20231005.dajohf2peiBu@digikod.net> In-Reply-To: From: Paul Moore Date: Tue, 17 Oct 2023 13:29:07 -0400 Message-ID: Subject: Re: RFC: New LSM to control usage of x509 certificates To: Mimi Zohar Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Eric Snowberg , "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@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: On Tue, Oct 17, 2023 at 1:09=E2=80=AFPM Mimi Zohar wr= ote: > On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote: > > On Tue, Oct 17, 2023 at 9:48=E2=80=AFAM Mimi Zohar wrote: > > > On Thu, 2023-10-05 at 12:32 +0200, Micka=C3=ABl Sala=C3=BCn 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 cons= traints. > > > > > > > > > > > > That is an interesting idea. Would the other security maintain= ers be in > > > > > > support of such an approach? Would a LSM be the correct interf= ace? > > > > > > 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 c= hanges can be > > > > > > viewed as a regression. Each end-user has different signing pr= ocedures > > > > > > and policies, so making something work for everyone is difficul= t. 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 th= is > > > 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=C3=ABl and Eric were thinking about a new LSM to control us= age > 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. --=20 paul-moore.com