On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:

On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar [off-list ref] wrote:

quoted

On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:

quoted

On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar [off-list ref] wrote:

quoted

On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:

quoted

quoted

quoted

quoted

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