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: <87a6ifehin.fsf@dja-thinkpad.axtens.net>
Date:   Mon, 08 Nov 2021 09:18:56 +1100
From:   Daniel Axtens <dja@...ens.net>
To:     Michal Suchánek <msuchanek@...e.de>,
        Mimi Zohar <zohar@...ux.ibm.com>
Cc:     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>
Subject: Re: [PATCH 0/3] KEXEC_SIG with appended signature

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 another amusing interaction is that if the IMA
verification is used, the signature could be in an xattr rather than an
appended signature.

Kind regards,
Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ