linux-kernel - Re: RFC: New LSM to control usage of x509 certificates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2512D2AE-4ACA-41B9-B9FB-C2B4802B9A10@oracle.com>
Date:   Tue, 17 Oct 2023 19:34:25 +0000
From:   Eric Snowberg <eric.snowberg@...cle.com>
To:     Paul Moore <paul@...l-moore.com>, Mimi Zohar <zohar@...ux.ibm.com>
CC:     Mickaël Salaün <mic@...ikod.net>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Kanth Ghatraju <kanth.ghatraju@...cle.com>,
        Konrad Wilk <konrad.wilk@...cle.com>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: RFC: New LSM to control usage of x509 certificates



> On Oct 17, 2023, at 12:51 PM, Paul Moore <paul@...l-moore.com> wrote:
> 
> On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@...ux.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@...ux.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@...ux.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