linux-kernel - Re: [PATCH 0/3] KEXEC_SIG with appended signature

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: <56d2ae87-b9bf-c9fc-1395-db4769a424ea@linux.vnet.ibm.com>
Date:   Thu, 11 Nov 2021 17:26:41 -0500
From:   Nayna <nayna@...ux.vnet.ibm.com>
To:     Michal Suchánek <msuchanek@...e.de>
Cc:     Mimi Zohar <zohar@...ux.ibm.com>, keyrings@...r.kernel.org,
        Rob Herring <robh@...nel.org>, linux-s390@...r.kernel.org,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Jessica Yu <jeyu@...nel.org>, linux-kernel@...r.kernel.org,
        David Howells <dhowells@...hat.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Paul Mackerras <paulus@...ba.org>,
        Hari Bathini <hbathini@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        linuxppc-dev@...ts.ozlabs.org,
        Frank van der Linden <fllinden@...zon.com>,
        Thiago Jung Bauermann <bauerman@...ux.ibm.com>,
        Daniel Axtens <dja@...ens.net>
Subject: Re: [PATCH 0/3] KEXEC_SIG with appended signature


On 11/8/21 07:05, Michal Suchánek wrote:
> Hello,
>
> On Mon, Nov 08, 2021 at 09:18:56AM +1100, Daniel Axtens wrote:
>> Michal Suchánek <msuchanek@...e.de> writes:
>>
>>> On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote:
>>>> Michal Suchanek <msuchanek@...e.de> writes:
>>>>
>>>>> S390 uses appended signature for kernel but implements the check
>>>>> separately from module loader.
>>>>>
>>>>> Support for secure boot on powerpc with appended signature is planned -
>>>>> grub patches submitted upstream but not yet merged.
>>>> Power Non-Virtualised / OpenPower already supports secure boot via kexec
>>>> with signature verification via IMA. I think you have now sent a
>>>> follow-up series that merges some of the IMA implementation, I just
>>>> wanted to make sure it was clear that we actually already have support
>>> So is IMA_KEXEC and KEXEC_SIG redundant?
>>>
>>> I see some architectures have both. I also see there is a lot of overlap
>>> between the IMA framework and the KEXEC_SIG and MODULE_SIg.
>>
>> Mimi would be much better placed than me to answer this.
>>
>> The limits of my knowledge are basically that signature verification for
>> modules and kexec kernels can be enforced by IMA policies.
>>
>> For example a secure booted powerpc kernel with module support will have
>> the following IMA policy set at the arch level:
>>
>> "appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig",
>> (in arch/powerpc/kernel/ima_arch.c)
>>
>> Module signature enforcement can be set with either IMA (policy like
>> "appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig" )
>> or with CONFIG_MODULE_SIG_FORCE/module.sig_enforce=1.
>>
>> Sometimes this leads to arguably unexpected interactions - for example
>> commit fa4f3f56ccd2 ("powerpc/ima: Fix secure boot rules in ima arch
>> policy"), so it might be interesting to see if we can make things easier
>> to understand.
> I suspect that is the root of the problem here. Until distributions pick
> up IMA and properly document step by step in detail how to implement,
> enable, and debug it the _SIG options are required for users to be able
> to make use of signatures.

For secureboot, IMA appraisal policies are configured in kernel at boot 
time based on secureboot state of the system, refer 
arch/powerpc/kernel/ima_arch.c and security/integrity/ima/ima_efi.c. 
This doesn't require any user configuration. Yes, I agree it would be 
helpful to update kernel documentation specifying steps to sign the 
kernel image using sign-file.

>
> The other part is that distributions apply 'lockdown' patches that change
> the security policy depending on secure boot status which were rejected
> by upstream which only hook into the _SIG options, and not into the IMA_
> options. Of course, I expect this to change when the IMA options are
> universally available across architectures and the support picked up by
> distributions.
>
> Which brings the third point: IMA features vary across architectures,
> and KEXEC_SIG is more common than IMA_KEXEC.
>
> config/arm64/default:CONFIG_HAVE_IMA_KEXEC=y
> config/ppc64le/default:CONFIG_HAVE_IMA_KEXEC=y
>
> config/arm64/default:CONFIG_KEXEC_SIG=y
> config/s390x/default:CONFIG_KEXEC_SIG=y
> config/x86_64/default:CONFIG_KEXEC_SIG=y
>
> KEXEC_SIG makes it much easier to get uniform features across
> architectures.

Architectures use KEXEC_SIG vs IMA_KEXEC based on their requirement. 
IMA_KEXEC is for the kernel images signed using sign-file (appended 
signatures, not PECOFF), provides measurement along with verification, 
and is tied to secureboot state of the system at boot time.

Thanks & Regards,

       - Nayna