All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Paul Moore <paul@paul-moore.com>
Cc: "Mickaël Salaün" <mic@digikod.net>,
	"Eric Snowberg" <eric.snowberg@oracle.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"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 13:58:27 -0400	[thread overview]
Message-ID: <5c795b4cf6d7460af205e85a36194fa188136c38.camel@linux.ibm.com> (raw)
In-Reply-To: <CAHC9VhS_Ttdy5ZB=jYdVfNyaJfn_7G1wztr5+g0g7uUDForXvA@mail.gmail.com>

On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:
> On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
> > > On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> 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.  For example, different
applications could be signed with different keys and should only be
verified with the specific key.

-- 
thanks,

Mimi


  reply	other threads:[~2023-10-17 17:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-08 21:34 [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring Eric Snowberg
2023-09-11 13:29 ` Mimi Zohar
2023-09-11 16:51   ` Mickaël Salaün
2023-09-11 22:17     ` Eric Snowberg
2023-09-11 23:08       ` Mimi Zohar
2023-09-12  2:00         ` Eric Snowberg
2023-09-12 11:54           ` Mimi Zohar
2023-09-12 17:11             ` Eric Snowberg
2023-09-12 22:47               ` Mimi Zohar
2023-09-13  2:40                 ` Eric Snowberg
2023-09-13 10:21                   ` Mickaël Salaün
2023-09-13 22:29                     ` Eric Snowberg
2023-09-14  8:34                       ` 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
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 [this message]
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
2023-09-11 22:04   ` [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring Jarkko Sakkinen
2023-09-11 22:23     ` Eric Snowberg
2023-09-11 22:01 ` Jarkko Sakkinen

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=5c795b4cf6d7460af205e85a36194fa188136c38.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.