From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: David Safford <safford@watson.ibm.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
James Morris <jmorris@namei.org>, Greg KH <greg@kroah.com>,
Dmitry Kasatkin <dmitry.kasatkin@nokia.com>
Subject: Re: [PATCH v5 00/21] EVM
Date: Tue, 31 May 2011 08:05:08 -0400 [thread overview]
Message-ID: <1306843508.3181.94.camel@localhost.localdomain> (raw)
In-Reply-To: <20110529065818.GA2122@elf.ucw.cz>
On Sun, 2011-05-29 at 08:58 +0200, Pavel Machek wrote:
> On Fri 2011-05-27 13:45:51, David Safford wrote:
> > On Thu, 2011-05-26 at 22:17 +0200, Pavel Machek wrote:
> >
> > > I suggest you explain the patchset in the emails, then? Everyone here
> > > seems to be confused... Attack it protects against, and what kind of
> > > hardware is needed for the protection to be effective?
> >
> > The white paper is over 15 pages, and it barely scratches the surface.
> > Every customer has different security threat models and requirements.
> > Discussing this in general on the mailing list is really hard.
> >
> > So let's try to simplify this just down to digital signatures in
> > the cellphone environment, as you state:
>
> Good.
>
> > > Because AFAICT, file signatures, as proposed, are only useful for
> > > locking down my cellphone against myself. (That's -- evil).
> >
> > The proposed digital signatures can enforce authenticity of a file's
> > data (IMA-Appraisal with Digital Signature), and of a file's metadata
> > (EVM with Digital Signature). For most users, enforcing authenticity
> > of files is a good thing - a user knows that they are running authentic
> > software signed by their phone manufacturer, and not malicious files
> > that they, or someone else installed. In this threat model, EVM is
>
> Ok, so lets talk about smartphone, similar to my HTC Dream (developer
> version, unlocked bootloader, flashable from kernel (*)).
>
> Yes, I could install the crazy EVM/IMA infastructure to prevent
> applications modifying selected files.
>
> But... I could just do chattr +i on selected files, I do not need
> fancy EVM/IMA for that.
For files that you don't expect to change, such as ELF executables, you
probably could use the immutable flag, but using a digital signature
provides authenticity as well, which the immutable flag does not
provide.
> > Blocking signature verification would serve only to punish Linux
> > users who care about the authenticity of their files, while doing
> > _nothing_ to stop manufacturers from locking their bootloaders.
>
> chattr already protects authenticity of my files, as do standard unix
> permissions.
>
> So... where's the difference?
> Pavel
Neither digital signatures nor the immutable flag work for files that
change, such as config files. For these files, ima-appraisal would
store a file hash.
> (*) but it does not change anything.
>
> True; determined attacker could steal my cellphone, open it up,
> desolder the flash, and change attributes of the filesystem.
With EVM, assuming that i_flag is included in the EVM HMAC, which it
currently isn't, you would be able to detect the change and prevent the
file from being accessed.
>
> But... the same determined attacker can also replace
> bootloader&kernel&filesystem -- that is in the same flash! -- with
> unlocked versions. So the argumentation is the same for locked down
> phone.
>
As EVM is not involved in the boot process, it can not and does not
address this, but other technologies could.
thanks,
Mimi
next prev parent reply other threads:[~2011-05-31 12:05 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-16 14:44 [PATCH v5 00/21] EVM Mimi Zohar
2011-05-16 14:44 ` [PATCH v5 01/21] integrity: move ima inode integrity data management Mimi Zohar
2011-05-19 2:06 ` Serge E. Hallyn
2011-05-19 22:45 ` Mimi Zohar
2011-05-16 14:44 ` [PATCH v5 02/21] xattr: define vfs_getxattr_alloc and vfs_xattr_cmp Mimi Zohar
2011-05-19 2:11 ` Serge E. Hallyn
2011-05-16 14:44 ` [PATCH v5 03/21] evm: re-release Mimi Zohar
2011-05-19 6:05 ` Serge E. Hallyn
2011-05-19 22:49 ` Mimi Zohar
2011-05-20 11:12 ` Harald Hoyer
2011-05-20 11:21 ` Mimi Zohar
2011-05-19 21:37 ` Serge E. Hallyn
2011-05-20 12:29 ` Mimi Zohar
2011-05-20 13:43 ` Serge E. Hallyn
2011-05-16 14:44 ` [PATCH v5 04/21] evm: add support for different security.evm data types Mimi Zohar
2011-05-16 14:44 ` [PATCH v5 05/21] ima: move ima_file_free before releasing the file Mimi Zohar
2011-05-19 22:06 ` Serge E. Hallyn
2011-05-20 0:55 ` Mimi Zohar
2011-05-20 13:40 ` Serge E. Hallyn
2011-05-20 14:34 ` Mimi Zohar
2011-05-20 15:25 ` Serge E. Hallyn
2011-05-16 14:45 ` [PATCH v5 06/21] security: imbed evm calls in security hooks Mimi Zohar
2011-05-19 22:13 ` Serge E. Hallyn
2011-05-16 14:45 ` [PATCH v5 07/21] evm: evm_inode_post_removexattr Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 08/21] evm: imbed evm_inode_post_setattr Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 09/21] evm: evm_inode_post_init Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 10/21] fs: add evm_inode_post_init calls Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 11/21] evm: crypto hash replaced by shash Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 12/21] evm: add evm_inode_post_init call in btrfs Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 13/21] evm: add evm_inode_post_init call in gfs2 Mimi Zohar
2011-05-16 15:30 ` Steven Whitehouse
2011-05-16 15:50 ` Mimi Zohar
2011-05-16 16:14 ` Steven Whitehouse
2011-05-16 16:35 ` Mimi Zohar
2011-05-16 17:50 ` Mimi Zohar
2011-05-16 17:57 ` Steven Whitehouse
2011-05-16 18:20 ` Mimi Zohar
2011-05-16 18:23 ` Casey Schaufler
2011-05-16 18:48 ` Mimi Zohar
2011-05-16 19:25 ` Casey Schaufler
2011-05-19 0:55 ` Mimi Zohar
2011-05-19 9:25 ` Steven Whitehouse
2011-05-16 14:45 ` [PATCH v5 14/21] evm: add evm_inode_post_init call in jffs2 Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 15/21] evm: add evm_inode_post_init call in jfs Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 16/21] evm: add evm_inode_post_init call in xfs Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 17/21] evm: additional parameter to pass integrity cache entry 'iint' Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 18/21] evm: evm_verify_hmac must not return INTEGRITY_UNKNOWN Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 19/21] evm: replace hmac_status with evm_status Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 20/21] evm: permit only valid security.evm xattrs to be updated Mimi Zohar
2011-05-16 14:45 ` [PATCH v5 21/21] evm: add evm_inode_setattr to prevent updating an invalid security.evm Mimi Zohar
2011-05-19 0:25 ` [PATCH v5 00/21] EVM Andrew Morton
2011-05-19 1:51 ` Mimi Zohar
2011-05-20 0:51 ` James Morris
2011-05-20 1:07 ` Mimi Zohar
2011-05-20 13:06 ` David Safford
2011-05-20 14:13 ` Casey Schaufler
2011-05-26 6:08 ` Pavel Machek
2011-05-26 16:34 ` Casey Schaufler
2011-05-26 18:11 ` David Safford
2011-05-26 18:38 ` Pavel Machek
2011-05-26 19:30 ` Casey Schaufler
2011-05-26 20:02 ` Pavel Machek
2011-05-26 20:32 ` Casey Schaufler
2011-05-26 19:49 ` Mimi Zohar
2011-05-26 20:17 ` Pavel Machek
2011-05-27 17:45 ` David Safford
2011-05-29 6:58 ` Pavel Machek
2011-05-31 12:05 ` Mimi Zohar [this message]
2011-05-31 13:40 ` Valdis.Kletnieks
2011-06-01 22:11 ` Dmitry Kasatkin
2011-05-20 18:50 ` Serge E. Hallyn
2011-05-23 22:09 ` 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=1306843508.3181.94.camel@localhost.localdomain \
--to=zohar@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=casey@schaufler-ca.com \
--cc=dmitry.kasatkin@nokia.com \
--cc=greg@kroah.com \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=safford@watson.ibm.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).