> On Oct 19, 2023, at 3:12 AM, Mickaël Salaün <mic@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx> wrote: >>>>> >>>>> On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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? > 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?
