From: James Morris on
On Tue, 1 Jun 2010, Mimi Zohar wrote:

> SELinux, Smack, Capabilities, and IMA all use extended attributes. The
> purpose of EVM is to detect offline tampering of these security extended
> attributes.

One issue mentioned to me off-list is that if EVM is only protecting
against offline attacks, why not just encrypt the entire volume ?

This would provide confidentiality and integrity protection for all data
and metadata, rather than just integrity for xattr metadata.


- James
--
James Morris
<jmorris(a)namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Shaz on
> 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?

> the types of files to those that don't change, and the number of file
> hashes, then using a single file would be faster.



--
Shaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Shaz on
On Fri, Jun 4, 2010 at 5:57 AM, James Morris <jmorris(a)namei.org> wrote:
> On Tue, 1 Jun 2010, Mimi Zohar wrote:
>
>> SELinux, Smack, Capabilities, and IMA all use extended attributes. The
>> purpose of EVM is to detect offline tampering of these security extended
>> attributes.
>
> One issue mentioned to me off-list is that if EVM is only protecting
> against offline attacks, why not just encrypt the entire volume ?

Are you sure that EVM protects against offline attacks only?

Why and why not encrypt the whole volume?

> This would provide confidentiality and integrity protection for all data
> and metadata, rather than just integrity for xattr metadata.


--
Shaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mimi Zohar on
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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Shaz on
On Fri, Jun 4, 2010 at 8:09 PM, Mimi Zohar <zohar(a)linux.vnet.ibm.com> wrote:
> 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

What if the sensitive files (binary or data) are compared with IMA
measurements after trusted boot or at anytime a stakeholder wants to?
The comparisons made with IMA will be the sha1 (or ....) of the files
stored in that one verification file. The stakeholder's key determines
which measurements can be compared by her (privacy protection and
confidentiality). Better use this key for an equivalence mechanism for
the factor of performance. The stakeholder's key as an identity can
help to make remote attestation more sensible as well. And here you
will be moving towards TCG MPWG standards .....

Combine this with SELinux or some RBAC mechanism and hopefully you
will get something closer to what MeeGo is trying to achieve. Consider
a trusted package manager with a registry sort of functionality for
files and it's owners and users and you've got a complete solution.

The worst part is that achieving performance is tough, while space is
not a serious issue.

>> > 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


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