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: <20211124120950.57c10a9f@rhtmp>
Date:   Wed, 24 Nov 2021 12:09:50 +0100
From:   Philipp Rudo <prudo@...hat.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>
Cc:     Michal Suchánek <msuchanek@...e.de>,
        Nayna <nayna@...ux.vnet.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>, buendgen@...ibm.com
Subject: Re: [PATCH 0/3] KEXEC_SIG with appended signature

Hi Mimi,

On Fri, 19 Nov 2021 13:16:20 -0500
Mimi Zohar <zohar@...ux.ibm.com> wrote:

> On Fri, 2021-11-19 at 12:18 +0100, Michal Suchánek wrote:
> > Maybe I was not clear enough. If you happen to focus on an architecture
> > that supports IMA fully it's great.
> > 
> > My point of view is maintaining multiple architectures. Both end users
> > and people conecerend with security are rarely familiar with
> > architecture specifics. Portability of documentation and debugging
> > instructions across architectures is a concern.
> > 
> > IMA has large number of options with varying availablitily across
> > architectures for no apparent reason. The situation is complex and hard
> > to grasp.  
> 
> IMA measures, verifies, and audits the integrity of files based on a
> system wide policy.  The known "good" integrity value may be stored in
> the security.ima xattr or more recently as an appended signature.
> 
> With both IMA kexec appraise and measurement policy rules, not only is
> the kernel image signature verified and the file hash included in the
> IMA measurement list, but the signature used to verify the integrity of
> the kexec kernel image is also included in the IMA measurement list
> (ima_template=ima-sig).
> 
> Even without PECOFF support in IMA, IMA kexec measurement policy rules
> can be defined to supplement the KEXEC_SIG signature verfication.
>
> > In comparison the *_SIG options are widely available. The missing
> > support for KEXEC_SIG on POWER is trivial to add by cut&paste from s390.
> > With that all the documentation that exists already is also trivially
> > applicable to POWER. Any additional code cleanup is a bonus but not
> > really needed to enable the kexec lockdown on POWER.  
> 
> Before lockdown was upstreamed, Matthew made sure that IMA signature
> verification could co-exist.   Refer to commit 29d3c1c8dfe7 ("kexec:
> Allow kexec_file() with appropriate IMA policy when locked down").   If
> there is a problem with the downstream kexec lockdown patches, they
> should be fixed.
> 
> The kexec kselftest might provide some insight into how the different
> signature verification methods and lockdown co-exist.
> 
> As for adding KEXEC_SIG appended signature support on PowerPC based on
> the s390 code, it sounds reasonable.

Heiko contacted me as you apparently requested that someone from s390
takes part in this discussion. I now spend over a day trying to make
any sens from this discussion but failed. The way I see it is.

On one hand there is KEXEC_SIG which is specifically designed to verify
the signatures of kernel images in kexec_file_load. From the beginning
it was designed in a way that every architecture (in fact even every
image type) can define its own callback function as needed. It's design
is simple and easy to extend and thus was adopted by all architectures,
except ppc, so far.

On the other hand there is IMA which is much more general and also
includes the same functionality like KEXEC_SIG but only on some
architectures in some special cases and without proper documentation.

Now Michal wants to adapt KEXEC_SIG for ppc too so distros can rely on all
architectures using the same mechanism and thus reduce maintenance cost.
On the way there he even makes some absolutely reasonable improvements
for everybody.

Why is that so controversial? What is the real problem that should be
discussed here?

Thanks
Philipp