From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
Patrick Ohly <patrick.ohly@intel.com>,
James Morris <james.l.morris@oracle.com>
Cc: Matthew Garrett <mjg59@google.com>,
linux-integrity <linux-integrity@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Silviu Vlasceanu <silviu.vlasceanu@huawei.com>,
"Safford, David (GE Global Research, US)" <david.safford@ge.com>
Subject: Re: IMA appraisal master plan?
Date: Tue, 21 Nov 2017 09:05:48 -0500 [thread overview]
Message-ID: <1511273148.4729.206.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <fd3f5cd3-a6a8-a540-f634-4ac489a171e8@huawei.com>
On Tue, 2017-11-21 at 10:33 +0100, Roberto Sassu wrote:
> On 11/20/2017 11:20 AM, Patrick Ohly wrote:
> > On Mon, 2017-11-20 at 07:47 +1100, James Morris wrote:
> >> On Fri, 17 Nov 2017, Roberto Sassu wrote:
> >>
> >>> LSMs are responsible to enforce a security policy at run-time,
> >>> while IMA/EVM protect data and metadata against offline attacks.
> >>
> >> In my view, IMA can also protect against making an online attack
> >> persistent across boots, and that would be the most compelling use of
> >> it for many general purpose applications.
>
> It would be possible, if IMA knows when the system is in the expected
> state. For example, if the system is in the expected state after digest
> lists have been loaded, IMA could erase the EVM key, sealed to that
> state, when a file with unknown digest is measured. The system won't be
> able to produce valid HMACs, and files modified after the attack can be
> identified at the next boot, due to the invalid HMAC. Also accessing
> files with invalid HMAC will cause the EVM key to be zeroed.
Roberto, allowing the system to boot with an EVM HMAC key, but then
transition to a point when it can't be used, is a good idea. The
transitioning, however, shouldn't be tied to white lists. Please keep
these concepts independent of each other.
Preventing a device from booting is major. Is there a less drastic
solution that would allow detection, without resealing the EVM HMAC
key so it can't be used?
Years ago Dave and I had a prototype of "locking" mutable files, after
a certain point in the boot process, working. It allowed the ~20
mutable files to be created/updated, as necessary. The limitation was
that any package updates or new packages installations needed to be
done during this window, before the transition, as well.
Mimi
WARNING: multiple messages have this Message-ID (diff)
From: zohar@linux.vnet.ibm.com (Mimi Zohar)
To: linux-security-module@vger.kernel.org
Subject: IMA appraisal master plan?
Date: Tue, 21 Nov 2017 09:05:48 -0500 [thread overview]
Message-ID: <1511273148.4729.206.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <fd3f5cd3-a6a8-a540-f634-4ac489a171e8@huawei.com>
On Tue, 2017-11-21 at 10:33 +0100, Roberto Sassu wrote:
> On 11/20/2017 11:20 AM, Patrick Ohly wrote:
> > On Mon, 2017-11-20 at 07:47 +1100, James Morris wrote:
> >> On Fri, 17 Nov 2017, Roberto Sassu wrote:
> >>
> >>> LSMs are responsible to enforce a security policy at run-time,
> >>> while IMA/EVM protect data and metadata against offline attacks.
> >>
> >> In my view, IMA can also protect against making an online attack
> >> persistent across boots, and that would be the most compelling use of
> >> it?for many general purpose applications.
>
> It would be possible, if IMA knows when the system is in the expected
> state. For example, if the system is in the expected state after digest
> lists have been loaded, IMA could erase the EVM key, sealed to that
> state, when a file with unknown digest is measured. The system won't be
> able to produce valid HMACs, and files modified after the attack can be
> identified at the next boot, due to the invalid HMAC. Also accessing
> files with invalid HMAC will cause the EVM key to be zeroed.
Roberto, allowing the system to boot with an EVM HMAC key, but then
transition to a point when it can't be used, is a good idea. ?The
transitioning, however, shouldn't be tied to white lists. ?Please keep
these concepts independent of each other.
Preventing a device from booting is major. ?Is there a less drastic
solution that would allow detection, without resealing the EVM HMAC
key so it can't be used?
Years ago Dave and I had a prototype of "locking" mutable files, after
a certain point in the boot process, working. ?It allowed the ~20
mutable files to be created/updated, as necessary. ?The limitation was
that any package updates or new packages installations needed to be
done during this window, before the transition, as well.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-11-21 14:05 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-07 15:17 [PATCH V6] EVM: Add support for portable signature format Matthew Garrett
2017-11-08 19:37 ` Mimi Zohar
2017-11-15 17:26 ` IMA appraisal master plan? (was: Re: [PATCH V6] EVM: Add support for portable signature format) Patrick Ohly
2017-11-15 17:58 ` Matthew Garrett
2017-11-15 18:21 ` Patrick Ohly
2017-11-15 18:28 ` Matthew Garrett
2017-11-16 0:02 ` James Morris
2017-11-16 0:05 ` Matthew Garrett
2017-11-16 2:13 ` Mimi Zohar
2017-11-16 9:23 ` IMA appraisal master plan? Roberto Sassu
2017-11-16 10:20 ` Patrick Ohly
2017-11-16 13:13 ` Mimi Zohar
2017-11-16 14:18 ` Roberto Sassu
2017-11-16 13:06 ` Mimi Zohar
2017-11-17 12:20 ` Roberto Sassu
2017-11-17 12:20 ` Roberto Sassu
2017-11-17 13:42 ` Mimi Zohar
2017-11-17 13:42 ` Mimi Zohar
2017-11-17 14:32 ` Roberto Sassu
2017-11-17 14:32 ` Roberto Sassu
2017-11-17 15:58 ` Stephen Smalley
2017-11-17 17:54 ` Stephen Smalley
2017-11-17 20:09 ` Safford, David (GE Global Research, US)
2017-11-18 19:29 ` Casey Schaufler
2017-11-19 20:47 ` James Morris
2017-11-19 20:47 ` James Morris
2017-11-20 10:20 ` Patrick Ohly
2017-11-20 10:20 ` Patrick Ohly
2017-11-20 14:59 ` Mimi Zohar
2017-11-20 14:59 ` Mimi Zohar
2017-11-20 16:15 ` Patrick Ohly
2017-11-20 16:15 ` Patrick Ohly
2017-11-21 10:05 ` James Morris
2017-11-21 10:05 ` James Morris
2017-11-21 9:33 ` Roberto Sassu
2017-11-21 9:33 ` Roberto Sassu
2017-11-21 14:05 ` Mimi Zohar [this message]
2017-11-21 14:05 ` Mimi Zohar
2017-11-21 15:25 ` Roberto Sassu
2017-11-21 15:25 ` Roberto Sassu
2017-11-21 15:53 ` Mimi Zohar
2017-11-21 15: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=1511273148.4729.206.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=david.safford@ge.com \
--cc=james.l.morris@oracle.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mjg59@google.com \
--cc=patrick.ohly@intel.com \
--cc=roberto.sassu@huawei.com \
--cc=silviu.vlasceanu@huawei.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.