linux-kernel - Re: [PATCH 0/2] ima: policy search speedup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Dec 2012 13:59:52 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Eric Paris <eparis@...isplace.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	James Morris <jmorris@...ei.org>
Subject: Re: [PATCH 0/2] ima: policy search speedup

On Tue, 2012-12-11 at 13:35 -0500, Eric Paris wrote:
> On Tue, Dec 11, 2012 at 1:18 PM, Mimi Zohar <zohar@...ux.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/