From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Shaz <shazalive@gmail.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@nokia.com>,
James Morris <jmorris@namei.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
David Safford <safford@watson.ibm.com>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Arjan van de Ven <arjan@infradead.org>,
securityengineeringresearchgroup
<securityengineeringresearchgroup@googlegroups.com>
Subject: Re: [PATCH 00/14] EVM
Date: Fri, 04 Jun 2010 11:09:18 -0400 [thread overview]
Message-ID: <1275664158.3205.27.camel@localhost.localdomain> (raw)
In-Reply-To: <AANLkTinIVaTocIgStpwKlXDByS7Z9t_OxJDYg0DoUMIN@mail.gmail.com>
On Fri, 2010-06-04 at 11:53 +0500, Shaz wrote:
> > Yes, verifying one file containing the hashes would be faster than
> > verifying individual hashes stored as extended attributes (xattrs), but
> > this does not take into account that files on a running system are being
> > modified or added. On a small form factor, the number of files is
> > limited, but would this scale well? In addition, what protects that one
> > file containing all the hashes from being modified? So, if you limit
>
> How about sealing to protect this file?
Was just indicating that the file needs to be protected. So, yes sealing
the file, based on PCRs, would work in a trusted boot environment.
> > the types of files to those that don't change, and the number of file
> > hashes, then using a single file would be faster.
Mimi
next prev parent reply other threads:[~2010-06-04 15:09 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-21 21:49 [PATCH 00/14] EVM Mimi Zohar
2010-04-21 21:49 ` [PATCH 01/14] integrity: move ima inode integrity data management Mimi Zohar
2010-04-21 21:49 ` [PATCH 02/14] security: move LSM xattrnames to xattr.h Mimi Zohar
2010-04-21 21:49 ` [PATCH 03/14] xattr: define vfs_getxattr_alloc and vfs_xattr_cmp Mimi Zohar
2010-04-26 18:50 ` Serge E. Hallyn
2010-04-21 21:49 ` [PATCH 04/14] evm: re-release Mimi Zohar
2010-04-26 21:03 ` Serge E. Hallyn
2010-06-04 14:28 ` Stephen Smalley
2010-06-04 14:53 ` Mimi Zohar
2010-06-04 15:20 ` Stephen Smalley
2010-06-04 18:08 ` David Safford
2010-04-21 21:49 ` [PATCH 05/14] ima: move ima_file_free before releasing the file Mimi Zohar
2010-04-21 21:49 ` [PATCH 06/14] security: imbed evm calls in security hooks Mimi Zohar
2010-04-21 21:49 ` [PATCH 07/14] evm: inode post removexattr Mimi Zohar
2010-04-21 21:49 ` [PATCH 08/14] evm: imbed evm_inode_post_setattr Mimi Zohar
2010-04-21 21:49 ` [PATCH 09/14] evm: inode_post_init Mimi Zohar
2010-04-21 21:49 ` [PATCH 10/14] fs: add evm_inode_post_init calls Mimi Zohar
2010-04-21 21:49 ` [PATCH 11/14] ima: integrity appraisal extension Mimi Zohar
2010-04-21 21:49 ` [PATCH 12/14] ima: appraise default rules Mimi Zohar
2010-04-21 21:49 ` [PATCH 13/14] ima: inode post_setattr Mimi Zohar
2010-04-21 21:49 ` [PATCH 14/14] ima: add ima_inode_setxattr and ima_inode_removexattr Mimi Zohar
2010-04-21 21:58 ` [PATCH 00/14] EVM Randy Dunlap
2010-04-21 22:18 ` Mimi Zohar
2010-04-21 22:23 ` Randy Dunlap
2010-04-21 22:41 ` Mimi Zohar
2010-05-31 0:20 ` James Morris
2010-05-31 10:02 ` Shaz
2010-05-31 10:08 ` Shaz
2010-06-01 19:28 ` Mimi Zohar
2010-06-02 7:03 ` Dmitry Kasatkin
2010-06-02 7:50 ` Shaz
2010-06-02 9:12 ` Dmitry Kasatkin
2010-06-02 10:15 ` Shaz
2010-06-02 10:23 ` Dmitry Kasatkin
2010-06-02 14:02 ` Mimi Zohar
2010-06-04 6:53 ` Shaz
2010-06-04 15:09 ` Mimi Zohar [this message]
2010-06-04 18:47 ` Shaz
2010-06-04 0:57 ` James Morris
2010-06-04 6:56 ` Shaz
2010-06-04 20:25 ` [ProbableSpam] " David Safford
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=1275664158.3205.27.camel@localhost.localdomain \
--to=zohar@linux.vnet.ibm.com \
--cc=arjan@infradead.org \
--cc=dave@linux.vnet.ibm.com \
--cc=dmitry.kasatkin@nokia.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=safford@watson.ibm.com \
--cc=securityengineeringresearchgroup@googlegroups.com \
--cc=shazalive@gmail.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.