All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
	dmitry.kasatkin@huawei.com, mjg59@google.com
Cc: linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org,
	silviu.vlasceanu@huawei.com
Subject: Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
Date: Fri, 07 Jun 2019 10:24:22 -0400	[thread overview]
Message-ID: <1559917462.4278.253.camel@linux.ibm.com> (raw)
In-Reply-To: <20190606112620.26488-3-roberto.sassu@huawei.com>

Hi Roberto,

Thank you for updating the patch description.

On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
> IMA and EVM have been designed as two independent subsystems: the first for
> checking the integrity of file data; the second for checking file metadata.
> Making them independent allows users to adopt them incrementally.
> 
> The point of intersection is in IMA-Appraisal, which calls
> evm_verifyxattr() to ensure that security.ima wasn't modified during an
> offline attack. The design choice, to ensure incremental adoption, was to
> continue appraisal verification if evm_verifyxattr() returns
> INTEGRITY_UNKNOWN. This value is returned when EVM is not enabled in the
> kernel configuration, or if the HMAC key has not been loaded yet.
> 
> Although this choice appears legitimate, it might not be suitable for
> hardened systems, where the administrator expects that access is denied if
> there is any error. An attacker could intentionally delete the EVM keys
> from the system and set the file digest in security.ima to the actual file
> digest so that the final appraisal status is INTEGRITY_PASS.

Assuming that the EVM HMAC key is stored in the initramfs, not on some
other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
would be limited to the rootfs filesystem.

> 
> This patch allows such hardened systems to strictly enforce an access
> control policy based on the validity of signatures/HMACs, by introducing
> two new values for the ima_appraise= kernel option: enforce-evm and
> log-evm.
> 

This patch defines a global policy requiring EVM on all filesystems.
I've previously suggested extending the IMA policy to support
enforcing or maybe exempting EVM on a per IMA policy rule basis.  As
seen by the need for an additional patch, included in this patch set,
which defines a temporary random number HMAC key to address
INTEGRITY_UNKNOWN on the rootfs filesystem, exempting certain
filesystems on a per policy rule basis might be simpler and achieve
similar results.

I'd like to hear other people's thoughts on defining a temporary,
random number HMAC key.

thanks,

Mimi


  reply	other threads:[~2019-06-07 14:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-06 11:26 [PATCH v3 0/2] ima/evm fixes for v5.2 Roberto Sassu
2019-06-06 11:26 ` [PATCH v3 1/2] evm: add option to set a random HMAC key at early boot Roberto Sassu
2019-06-06 11:26 ` [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status Roberto Sassu
2019-06-07 14:24   ` Mimi Zohar [this message]
2019-06-07 14:40     ` Roberto Sassu
2019-06-07 15:08       ` Mimi Zohar
2019-06-07 15:14         ` Roberto Sassu
2019-06-07 15:25           ` Mimi Zohar
2019-06-06 11:43 ` [PATCH v3 0/2] ima/evm fixes for v5.2 Roberto Sassu
2019-06-06 14:49   ` Mimi Zohar
2019-06-06 15:22     ` Roberto Sassu
2019-06-12 11:28 ` Janne Karhunen
2019-06-12 13:11   ` Roberto Sassu
2019-06-12 13:38     ` Janne Karhunen
2019-06-12 16:33       ` Roberto Sassu
2019-06-13  6:01         ` Janne Karhunen
2019-06-13  6:57           ` Roberto Sassu
2019-06-13  7:39             ` Janne Karhunen
2019-06-13  7:50               ` Roberto Sassu
2019-06-13  8:04                 ` Janne Karhunen
2019-06-13  8:51                   ` Roberto Sassu

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=1559917462.4278.253.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=dmitry.kasatkin@huawei.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mjg59@google.com \
    --cc=roberto.sassu@huawei.com \
    --cc=silviu.vlasceanu@huawei.com \
    --cc=stable@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.