linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Eric Paris <eparis@parisplace.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Kasatkin, Dmitry" <dmitry.kasatkin@intel.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	James Morris <jmorris@namei.org>
Subject: Re: [PATCH 0/2] ima: policy search speedup
Date: Tue, 11 Dec 2012 13:59:52 -0500	[thread overview]
Message-ID: <1355252392.2356.131.camel@falcor> (raw)
In-Reply-To: <CACLa4pvLbrCbivWSNTuxROBf5qDNJZmnFVyQaQ=7qcZRtSfcfg@mail.gmail.com>

On Tue, 2012-12-11 at 13:35 -0500, Eric Paris wrote:
> On Tue, Dec 11, 2012 at 1:18 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > The appraisal policy is based on the object metadata, such as the uid,
> > so the result is static and can be cached.  The measurement policy, on
> > the other hand, is normally based on the subject (eg. who is
> > reading/executing) the file.  Knowledge of whether the file has been
> > measured is cached in the iint, but unlike the appraisal policy, not
> > whether it needs to be measured.  Having the flag on a per inode basis,
> > doesn't really help.
> 
> Can you try again?  Even I can't parse this.  Not sure what to tell
> you to try again, maybe give us a summary at a high level again and
> then why this patch is specifically necessary?

sigh. The IMA policy contains rules for the original IMA measurement,
hash auditing, and now for IMA appraisal.  These policies overlap with
each other, but are not the same.

Although the policy doesn't change, the rules can be dependent on the
calling process.  For example, the original default 'ima_tcb' policy is
based, not on the file owner, but on the uid reading/executing the file.
The 'ima_tcb' policy measures all files read/executed by root.  So we
cache whether the file has been measured, not if the file needs to be
measured, because depending on the caller, that changes.  Bottom line,
we can't say definitively whether or not a file needs to be measured for
any caller.

Dmitry's patch addresses the issue of eliminating an entire filesystem
from being appraised, measured, or audited.

I hope this clarifies the issues a bit better.

Mimi

 


  reply	other threads:[~2012-12-11 19:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-22 21:54 [PATCH 0/2] ima: policy search speedup Dmitry Kasatkin
2012-11-22 21:54 ` [PATCH 1/2] vfs: new super block feature flags attribute Dmitry Kasatkin
2012-11-22 21:54 ` [PATCH 2/2] ima: skip policy search for never appraised or measured files Dmitry Kasatkin
2012-11-27 13:42 ` [PATCH 0/2] ima: policy search speedup Kasatkin, Dmitry
2012-12-11 12:51   ` Kasatkin, Dmitry
2012-12-11 14:08     ` Mimi Zohar
2012-12-11 16:59       ` Linus Torvalds
2012-12-11 17:40         ` Kasatkin, Dmitry
2012-12-11 17:55           ` Linus Torvalds
2012-12-11 18:09             ` Eric Paris
2012-12-11 18:35               ` Kasatkin, Dmitry
2012-12-11 19:07               ` Mimi Zohar
2012-12-11 22:16                 ` Dave Chinner
2012-12-11 18:10             ` Kasatkin, Dmitry
2012-12-11 18:29               ` Al Viro
2012-12-11 18:12             ` Kasatkin, Dmitry
2012-12-11 18:35               ` Linus Torvalds
2012-12-11 18:53                 ` Kasatkin, Dmitry
2012-12-11 18:18         ` Mimi Zohar
2012-12-11 18:35           ` Eric Paris
2012-12-11 18:59             ` Mimi Zohar [this message]
2012-12-11 19:10               ` Linus Torvalds
2012-12-11 19:48                 ` Mimi Zohar
2012-12-11 20:05                   ` Linus Torvalds
2012-12-11 20:15                     ` Eric Paris
2012-12-11 20:31                       ` Linus Torvalds
2012-12-11 20:08                   ` Eric Paris
2012-12-11 22:57                     ` Kasatkin, Dmitry
2012-12-11 23:02                       ` Eric Paris
2012-12-12 13:56                         ` Kasatkin, Dmitry
2012-12-12 14:25                           ` Eric Paris

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=1355252392.2356.131.camel@falcor \
    --to=zohar@linux.vnet.ibm.com \
    --cc=dmitry.kasatkin@intel.com \
    --cc=eparis@parisplace.org \
    --cc=jmorris@namei.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).