From: Mimi Zohar <zohar@linux.ibm.com>
To: "Michal Suchánek" <msuchanek@suse.de>, Nayna <nayna@linux.vnet.ibm.com>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>,
Rob Herring <robh@kernel.org>, Vasily Gorbik <gor@linux.ibm.com>,
linux-s390@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
Luis Chamberlain <mcgrof@kernel.org>,
keyrings@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Frank van der Linden <fllinden@amazon.com>,
Jessica Yu <jeyu@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
buendgen@de.ibm.com, linuxppc-dev@lists.ozlabs.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
Hari Bathini <hbathini@linux.ibm.com>,
Daniel Axtens <dja@axtens.net>
Subject: Re: [PATCH 0/3] KEXEC_SIG with appended signature
Date: Fri, 19 Nov 2021 13:16:20 -0500 [thread overview]
Message-ID: <01218c22a287665091f24c7023f4bcd42dbb2001.camel@linux.ibm.com> (raw)
In-Reply-To: <20211119111823.GC34414@kunlun.suse.cz>
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.
thanks,
Mimi
next prev parent reply other threads:[~2021-11-19 18:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-03 14:27 [PATCH 0/3] KEXEC_SIG with appended signature Michal Suchanek
2021-11-03 14:27 ` [PATCH 1/3] s390/kexec_file: Don't opencode appended signature verification Michal Suchanek
2021-11-03 14:27 ` [PATCH 2/3] module: strip the signature marker in the verification function Michal Suchanek
2021-11-03 14:27 ` [PATCH 3/3] powerpc/kexec_file: Add KEXEC_SIG support Michal Suchanek
2021-11-05 9:55 ` [PATCH 0/2] Additional appended signature cleanup Michal Suchanek
2021-11-05 9:55 ` [PATCH 1/2] module: Use key_being_used_for for log messages in verify_appended_signature Michal Suchanek
2021-11-05 9:55 ` [PATCH 2/2] module: Move duplicate mod_check_sig users code to mod_parse_sig Michal Suchanek
2021-11-05 10:55 ` [PATCH 0/3] KEXEC_SIG with appended signature Daniel Axtens
2021-11-05 13:14 ` Michal Suchánek
2021-11-07 22:18 ` Daniel Axtens
2021-11-08 12:05 ` Michal Suchánek
2021-11-11 22:26 ` Nayna
2021-11-12 8:30 ` Michal Suchánek
2021-11-15 23:53 ` Nayna
2021-11-16 9:53 ` Michal Suchánek
2021-11-18 22:34 ` Nayna
2021-11-19 11:18 ` Michal Suchánek
2021-11-19 18:16 ` Mimi Zohar [this message]
2021-11-24 11:09 ` Philipp Rudo
2021-11-24 13:10 ` Mimi Zohar
2021-11-24 13:27 ` Michal Suchánek
2021-11-25 9:14 ` Philipp Rudo
2021-11-11 22:23 ` Nayna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01218c22a287665091f24c7023f4bcd42dbb2001.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=bauerman@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=buendgen@de.ibm.com \
--cc=dhowells@redhat.com \
--cc=dja@axtens.net \
--cc=fllinden@amazon.com \
--cc=gor@linux.ibm.com \
--cc=hbathini@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jeyu@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mcgrof@kernel.org \
--cc=msuchanek@suse.de \
--cc=nayna@linux.vnet.ibm.com \
--cc=nramas@linux.microsoft.com \
--cc=paulus@samba.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).