On Tue, Jan 25, 2022 at 07:06:57PM -0500, Mimi Zohar wrote:
> Instead of calculating a file hash and verifying the signature stored
> in the security.ima xattr against the calculated file hash, verify
> fs-verity's signature (version 3).
>
> To differentiate between a regular file hash and an fs-verity file digest
> based signature stored as security.ima xattr, define a new signature type
> named IMA_VERITY_DIGSIG.
>
> Update the 'ima-sig' template field to display the new fs-verity signature
> type as well.
>
> For example:
> appraise func=BPRM_CHECK digest_type=hash|verity
>
> Signed-off-by: Mimi Zohar <zohar@xxxxxxxxxxxxx>
> ---
> Documentation/ABI/testing/ima_policy | 10 +++++
> Documentation/security/IMA-templates.rst | 4 +-
> security/integrity/ima/ima_appraise.c | 49 ++++++++++++++++++++++-
> security/integrity/ima/ima_template_lib.c | 3 +-
> security/integrity/integrity.h | 5 ++-
> 5 files changed, 65 insertions(+), 6 deletions(-)
All this IMA-specific stuff is confusing to me, so let me ask a question about
what the end result actually is. Let's say I want to use IMA to authenticate
("appraise") a file. I've signed its fs-verity digest with a key. I put only
that one key in the IMA keyring, and that key was only ever used to sign that
one fs-verity digest. Can an attacker (who controls the file's contents and IMA
xattr) replace the file with one with a different contents and still pass the
IMA check? For example, could they replace the file's contents with the
ima_file_id of the authentic file, and then downgrade the signature version to
v2? If they can do that, then the goal of authentication wasn't met. It might
be necessary to enforce that only one signature version is used at a time, to
avoid this kind of ambiguity.
- Eric
