All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
	Mimi Zohar <zohar@linux.ibm.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,
	linux-kernel@vger.kernel.org, silviu.vlasceanu@huawei.com,
	stable@vger.kernel.org
Subject: Re: [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status
Date: Mon, 03 Jun 2019 16:43:21 +0300	[thread overview]
Message-ID: <1559569401.5052.17.camel@HansenPartnership.com> (raw)
In-Reply-To: <e6b31aa9-0319-1805-bdfc-3ddde5884494@huawei.com>

On Mon, 2019-06-03 at 11:25 +0200, Roberto Sassu wrote:
> On 5/30/2019 2:00 PM, Mimi Zohar wrote:
> > On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
> > > Currently, ima_appraise_measurement() ignores the EVM status when
> > > evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file has a
> > > valid security.ima xattr with type IMA_XATTR_DIGEST or
> > > IMA_XATTR_DIGEST_NG, ima_appraise_measurement() returns
> > > INTEGRITY_PASS regardless of the EVM status. The problem is that
> > > the EVM status is overwritten with the appraisal statu
> > 
> > Roberto, your framing of this problem is harsh and misleading.  IMA
> > and EVM are intentionally independent of each other and can be
> > configured independently of each other.  The intersection of the
> > two is the call to evm_verifyxattr().  INTEGRITY_UNKNOWN is
> > returned for a number of reasons - when EVM is not configured, the
> > EVM hmac key has not yet been loaded, the protected security
> > attribute is unknown, or the file is not in policy.
> > 
> > This patch does not differentiate between any of the above cases,
> > requiring mutable files to always be protected by EVM, when
> > specified as an "ima_appraise=" option on the boot command line.
> > 
> > IMA could be extended to require EVM on a per IMA policy rule
> > basis. Instead of framing allowing IMA file hashes without EVM as a
> > bug that has existed from the very beginning, now that IMA/EVM have
> > matured and is being used, you could frame it as extending IMA
> > or hardening.
> 
> I'm seeing it from the perspective of an administrator that manages
> an already hardened system, and expects that the system only grants
> access to files with a valid signature/HMAC. That system would not
> enforce this behavior if EVM keys are removed and the digest in
> security.ima is set to the actual file digest.
> 
> Framing it as a bug rather than an extension would in my opinion help
> to convince people about the necessity to switch to the safe mode, if
> their system is already hardened.

I have a use case for IMA where I use it to enforce immutability of
containers.  In this use case, the cluster admin places hashes on
executables as the image is unpacked so that if an executable file is
changed, IMA will cause an execution failure.  For this use case, I
don't care about the EVM, in fact we don't use it, because the only
object is to fail execution if a binary is mutated.

So I can see your use case requires IMA+EVM, but requiring it would
cause more complexity for my use case.

James


  parent reply	other threads:[~2019-06-03 13:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 13:30 [PATCH v2 0/3] ima/evm fixes for v5.2 Roberto Sassu
2019-05-29 13:30 ` [PATCH v2 1/3] evm: check hash algorithm passed to init_desc() Roberto Sassu
2019-05-30 11:53   ` Mimi Zohar
2019-05-29 13:30 ` [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status Roberto Sassu
2019-05-30 12:00   ` Mimi Zohar
2019-06-03  9:25     ` Roberto Sassu
2019-06-03 12:48       ` Mimi Zohar
2019-06-03 13:43       ` James Bottomley [this message]
2019-06-03 14:24         ` Chuck Lever
2019-06-03 14:29         ` Roberto Sassu
2019-06-03 14:31           ` James Bottomley
2019-06-03 14:44             ` Roberto Sassu
2019-06-04  8:57               ` James Bottomley
2019-05-29 13:30 ` [PATCH v2 3/3] ima: show rules with IMA_INMASK correctly Roberto Sassu
2019-05-30 11:53   ` Mimi Zohar

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=1559569401.5052.17.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.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 \
    --cc=zohar@linux.ibm.com \
    /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.