On Oct 19, 2023, at 3:12 AM, Mickaël Salaün [off-list ref] wrote:

On Wed, Oct 18, 2023 at 11:12:45PM +0000, Eric Snowberg wrote:

quoted

quoted

On Oct 18, 2023, at 8:14 AM, Mickaël Salaün [off-list ref] wrote:

On Tue, Oct 17, 2023 at 07:34:25PM +0000, Eric Snowberg wrote:

quoted

quoted

On Oct 17, 2023, at 12:51 PM, Paul Moore [off-list ref] wrote:

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

quoted

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

quoted

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.

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.

I agree, a configuration component for a sysadmin would be needed.

quoted

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).

If an LSM hook could dynamically filter keyrings, and the EKU was used, 
is there an opinion on how flexible this should be?  Meaning, should there 
be OIDs defined and carried in mainline code?  This would make it easier 
to setup and use.  However who would be the initial OID owner?  Or would 
predefined OIDs not be contained within mainline code, leaving it to the 
sysadmin to create a policy that would be fed to the LSM to do the filtering.

The more flexible approach would be to not hardcode any policy in the
kernel but let sysadmins define their own, including OIDs. We "just"
need to find an adequate configuration scheme to define these
constraints.

Also, with the flexible approach, the policy would need to be given to the 
kernel before any kernel module loads, fs-verity starts, or anything dealing 
with digital signature based IMA runs, etc.  With hardcoded policies this 
could be setup from the kernel command line or be set from a Kconfig.  
I assume with a flexible approach, this would need to come in early within 
the initram?

We already have an ASN.1 parser in the kernel, so we might
want to leverage that to match a certificate.

We have the parser, however after parsing the certificate we do not 
retain all the information within it.  Some of the recent changes I have 
done required modifications to the public_key struct.  If there isn’t any 
type of hard coded policy, what would be the reception of retaining the 
entire cert within the kernel?