Thread (61 messages) 61 messages, 10 authors, 2020-08-14

Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)

From: Chuck Lever <hidden>
Date: 2020-08-13 14:56:26
Also in: dm-devel, linux-block, linux-fsdevel, linux-integrity, lkml

On Aug 13, 2020, at 10:42 AM, James Bottomley [off-list ref] wrote:

On Thu, 2020-08-13 at 10:21 -0400, Chuck Lever wrote:
quoted
quoted
On Aug 12, 2020, at 11:42 AM, James Bottomley <James.Bottomley@Hans
enPartnership.com> wrote:
[...]
quoted
quoted
For most people the security mechanism of local xattrs is
sufficient.  If you're paranoid, you don't believe it is and you
use EVM.
When IMA metadata happens to be stored in local filesystems in
a trusted xattr, it's going to enjoy the protection you describe
without needing the addition of a cryptographic signature.

However, that metadata doesn't live its whole life there. It
can reside in a tar file, it can cross a network, it can live
on a back-up tape. I think we agree that any time that metadata
is in transit or at rest outside of a Linux local filesystem, it
is exposed.

Thus I'm interested in a metadata protection mechanism that does
not rely on the security characteristics of a particular storage
container. For me, a cryptographic signature fits that bill
nicely.
Sure, but one of the points about IMA is a separation of mechanism from
policy.  Signed hashes (called appraisal in IMA terms) is just one
policy you can decide to require or not or even make it conditional on
other things.
AFAICT, the current EVM_IMA_DIGSIG and EVM_PORTABLE_DIGSIG formats are
always signed. The policy choice is whether or not to verify the
signature, not whether or not the metadata format is signed.


--
Chuck Lever
chucklever@gmail.com


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help