Re: RFC: New LSM to control usage of x509 certificates

["Mickaël Salaün" <mic@digikod.net>]

On Thu, Oct 19, 2023 at 11:08:38PM +0000, Eric Snowberg wrote:
> 
> 
> > On Oct 19, 2023, at 3:12 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > 
> > On Wed, Oct 18, 2023 at 11:12:45PM +0000, Eric Snowberg wrote:
> >> 
> >> 
> >>> On Oct 18, 2023, at 8:14 AM, Mickaël Salaün <mic@digikod.net> wrote:
> >>> 
> >>> On Tue, Oct 17, 2023 at 07:34:25PM +0000, Eric Snowberg wrote:
> >>>> 
> >>>> 
> >>>>> On Oct 17, 2023, at 12:51 PM, Paul Moore <paul@paul-moore.com> wrote:
> >>>>> 
> >>>>> On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>>> 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.
> >>>>> 
> >>>>> 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.
> >> 
> >>> 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?

Yes, either the cmdline and/or the initramfs.

> 
> > 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? 

I think it would make sense to have a default policy loaded at boot
time, then load and take into account new pieces of policies at run
time, but only parse/tag/assign a role to certificates/keys when they
are loaded.