From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Matthew Garrett <mjg59@google.com>,
James Morris <james.l.morris@oracle.com>
Cc: Patrick Ohly <patrick.ohly@intel.com>,
linux-integrity <linux-integrity@vger.kernel.org>
Subject: Re: IMA appraisal master plan? (was: Re: [PATCH V6] EVM: Add support for portable signature format)
Date: Wed, 15 Nov 2017 21:13:02 -0500 [thread overview]
Message-ID: <1510798382.3711.389.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <CACdnJuv=YDngm5HqJT9sfM01AVoZUaf8_uu-ygo+h8nNjtsDeA@mail.gmail.com>
On Wed, 2017-11-15 at 16:05 -0800, Matthew Garrett wrote:
> On Wed, Nov 15, 2017 at 4:02 PM, James Morris <james.l.morris@oracle.com> wrote:
> > On Wed, 15 Nov 2017, Patrick Ohly wrote:
> >
> >> I have some experience with SMACK, but not with Apparmor. At least with
> >> SMACK the problem is that the LSM depends on integrity protection of
> >> the xattrs, but the integrity protection itself depends on the LSM, so
> >> there's a cycle. An attacker can much too easily make offline changes
> >> which then defeat whatever IMA policy the system might be using.
> >
> > Isn't this what EVM is supposed to mitigate?
>
> If the path to the loading of the LSM policy isn't fully appraised,
> then it can be modified offline in order to permit modification of the
> EVM xattrs at runtime, at which point the kernel will happily generate
> a new HMAC.
Matthew, your explanation is a valid problem, but different than what
Patrick was describing. Your description is of protecting the LSM
policy itself. Patrick, correct me if I'm wrong, was describing the
situation where the LSM labels are modified, causing the file being
appraised not to be in the IMA policy.
To solve Matthew's problem requires modifying the LSMs so that instead
of userspace reading the policy, processing it and loading it into the
kernel, the LSMs read the policy file directly.
Mimi
next prev parent reply other threads:[~2017-11-16 2:13 UTC|newest]
Thread overview: 29+ 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 [this message]
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 13:42 ` Mimi Zohar
2017-11-17 14:32 ` Roberto Sassu
2017-11-17 15:58 ` 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-20 10:20 ` Patrick Ohly
2017-11-20 14:59 ` Mimi Zohar
2017-11-20 16:15 ` Patrick Ohly
2017-11-21 10:05 ` James Morris
2017-11-21 9:33 ` Roberto Sassu
2017-11-21 14:05 ` Mimi Zohar
2017-11-21 15:25 ` Roberto Sassu
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=1510798382.3711.389.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=james.l.morris@oracle.com \
--cc=linux-integrity@vger.kernel.org \
--cc=mjg59@google.com \
--cc=patrick.ohly@intel.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 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).