lkml.org 
[lkml]   [2022]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v9 2/8] integrity: Introduce a Linux keyring called machine
    Date


    > On Jan 12, 2022, at 12:41 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
    >
    > On Tue, 2022-01-11 at 20:14 -0500, Mimi Zohar wrote:
    >> On Tue, 2022-01-11 at 21:26 +0000, Eric Snowberg wrote:
    >>>
    >>>> On Jan 11, 2022, at 11:16 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
    >>>>
    >>>> On Mon, 2022-01-10 at 23:25 +0000, Eric Snowberg wrote:
    >>>>>> Jarkko, my concern is that once this version of the patch set is
    >>>>>> upstreamed, would limiting which keys may be loaded onto the .machine
    >>>>>> keyring be considered a regression?
    >>>>>
    >>>>>
    >>>>> Currently certificates built into the kernel do not have a CA restriction on them.
    >>>>> IMA will trust anything in this keyring even if the CA bit is not set. While it would
    >>>>> be advisable for a kernel to be built with a CA, nothing currently enforces it.
    >>>>>
    >>>>> My thinking for the dropped CA restriction patches was to introduce a new Kconfig.
    >>>>> This Kconfig would do the CA enforcement on the machine keyring. However if the
    >>>>> Kconfig option was not set for enforcement, it would work as it does in this series,
    >>>>> plus it would allow IMA to work with non-CA keys. This would be done by removing
    >>>>> the restriction placed in this patch. Let me know your thoughts on whether this would
    >>>>> be an appropriate solution. I believe this would get around what you are identifying as
    >>>>> a possible regression.
    >>>>
    >>>> True the problem currently exists with the builtin keys, but there's a
    >>>> major difference between trusting the builtin keys and those being
    >>>> loading via MOK. This is an integrity gap that needs to be closed and
    >>>> shouldn't be expanded to keys on the .machine keyring.
    >>>>
    >>>> "plus it would allow IMA to work with non-CA keys" is unacceptable.
    >>>
    >>> Ok, I’ll leave that part out. Could you clarify the wording I should include in the future
    >>> cover letter, which adds IMA support, on why it is unacceptable for the end-user to
    >>> make this decision?
    >>
    >> The Kconfig IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
    >> "help" is very clear:
    >
    > [Reposting the text due to email formatting issues.]
    >
    > help
    > Keys may be added to the IMA or IMA blacklist keyrings, if the
    > key is validly signed by a CA cert in the system built-in or
    > secondary trusted keyrings.
    >
    > Intermediate keys between those the kernel has compiled in and the
    > IMA keys to be added may be added to the system secondary keyring,
    > provided they are validly signed by a key already resident in the
    > built-in or secondary trusted keyrings.
    >
    >
    > The first paragraph requires "validly signed by a CA cert in the system
    > built-in or secondary trusted keyrings" for keys to be loaded onto the
    > IMA keyring. This Kconfig is limited to just the builtin and secondary
    > keyrings. Changing this silently to include the ".machine" keyring
    > introduces integrity risks that previously did not exist. A new IMA
    > Kconfig needs to be defined to allow all three keyrings - builtin,
    > machine, and secondary.
    >
    > The second paragraph implies that only CA and intermediate CA keys are
    > on secondary keyring, or as in our case the ".machine" keyring linked
    > to the secondary keyring.

    Got it, thanks. I’ll use this in the cover letter that introduces the CA restrictions
    to enable IMA.

    \
     
     \ /
      Last update: 2022-01-13 00:02    [W:4.799 / U:0.772 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site