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