linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: "Mickaël Salaün" <mic@digikod.net>,
	"Eric Snowberg" <eric.snowberg@oracle.com>,
	"Paul Moore" <paul@paul-moore.com>,
	"Serge E. Hallyn" <serge@hallyn.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
	David Howells <dhowells@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Kanth Ghatraju <kanth.ghatraju@oracle.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org
Subject: Re: RFC: New LSM to control usage of x509 certificates
Date: Tue, 17 Oct 2023 09:39:21 -0400	[thread overview]
Message-ID: <d3b51f26c14fd273d41da3432895fdce9f4d047c.camel@linux.ibm.com> (raw)
In-Reply-To: <20231005.dajohf2peiBu@digikod.net>

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?

-- 
thanks,

Mimi


  parent reply	other threads:[~2023-10-17 13:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230911.chaeghaeJ4ei@digikod.net>
     [not found] ` <CEA476C1-4CE5-4FFC-91D7-6061C8605B18@oracle.com>
     [not found]   ` <ba2f5560800608541e81fbdd28efa9875b35e491.camel@linux.ibm.com>
     [not found]     ` <932231F5-8050-4436-84B8-D7708DC43845@oracle.com>
     [not found]       ` <7335a4587233626a39ce9bc8a969957d7f43a34c.camel@linux.ibm.com>
     [not found]         ` <FD6FB139-F901-4E55-9705-E7B0023BDBA8@oracle.com>
     [not found]           ` <1149b6dbfdaabef3e48dc2852cc76aa11a6dd6b0.camel@linux.ibm.com>
     [not found]             ` <4A0505D0-2933-43BD-BEEA-94350BB22AE7@oracle.com>
     [not found]               ` <20230913.Ceifae7ievei@digikod.net>
     [not found]                 ` <D0F16BFD-72EB-4BE2-BA3D-BAE1BCCDCB6F@oracle.com>
2023-09-14  8:34                   ` [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring Mickaël Salaün
2023-10-05 10:32                     ` RFC: New LSM to control usage of x509 certificates Mickaël Salaün
2023-10-05 14:05                       ` Paul Moore
2023-10-17 13:39                       ` Mimi Zohar [this message]
2023-10-17 15:45                         ` Paul Moore
2023-10-17 17:08                           ` Mimi Zohar
2023-10-17 17:29                             ` Paul Moore
2023-10-17 17:58                               ` Mimi Zohar
2023-10-17 18:51                                 ` Paul Moore
2023-10-17 19:34                                   ` Eric Snowberg
2023-10-18 14:14                                     ` Mickaël Salaün
2023-10-18 23:12                                       ` Eric Snowberg
2023-10-19  9:12                                         ` Mickaël Salaün
2023-10-19 23:08                                           ` Eric Snowberg
2023-10-20 15:05                                             ` Mickaël Salaün
2023-10-20 15:26                                               ` Roberto Sassu
2023-10-20 15:53                                               ` Eric Snowberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d3b51f26c14fd273d41da3432895fdce9f4d047c.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.snowberg@oracle.com \
    --cc=jarkko@kernel.org \
    --cc=kanth.ghatraju@oracle.com \
    --cc=keyrings@vger.kernel.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).