Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)
On Wed, 2020-08-05 at 09:59 -0700, James Morris wrote:
On Wed, 5 Aug 2020, James Bottomley wrote:
> I'll leave Mimi to answer, but really this is exactly the question that
> should have been asked before writing IPE. However, since we have the
> cart before the horse, let me break the above down into two specific
> questions.
The question is valid and it was asked. We decided to first prototype what
we needed and then evaluate if it should be integrated with IMA. We
discussed this plan in person with Mimi (at LSS-NA in 2019), and presented
a more mature version of IPE to LSS-NA in 2020, with the expectation that
such a discussion may come up (it did not).
When we first spoke the concepts weren't fully formulated, at least to
me.
These patches are still part of this process and 'RFC' status.
> 1. Could we implement IPE in IMA (as in would extensions to IMA cover
> everything). I think the answers above indicate this is a "yes".
It could be done, if needed.
> 2. Should we extend IMA to implement it? This is really whether from a
> usability standpoint two seperate LSMs would make sense to cover the
> different use cases.
One issue here is that IMA is fundamentally a measurement & appraisal
scheme which has been extended to include integrity enforcement. IPE was
designed from scratch to only perform integrity enforcement. As such, it
is a cleaner design -- "do one thing and do it well" is a good design
pattern.
In our use-case, we utilize _both_ IMA and IPE, for attestation and code
integrity respectively. It is useful to be able to separate these
concepts. They really are different:
- Code integrity enforcement ensures that code running locally is of known
provenance and has not been modified prior to execution.
- Attestation is about measuring the health of a system and having that
measurement validated by a remote system. (Local attestation is useless).
I'm not sure there is value in continuing to shoe-horn both of these into
IMA.
True, IMA was originally limited to measurement and attestation, but
most of the original EVM concepts were subsequently included in IMA.
(Remember, Reiner Sailer wrote the original IMA, which I inherited. I
was originially working on EVM code integrity.) From a naming
perspective including EVM code integrity in IMA was a mistake. My
thinking at the time was that as IMA was already calculating the file
hash, instead of re-calculating the file hash for integrity, calculate
the file hash once and re-use it for multiple things - measurement,
integrity, and audit. At the same time define a single system wide
policy.
When we first started working on IMA, EVM, trusted, and encrypted keys,
the general kernel community didn't see a need for any of it. Thus, a
lot of what was accomplished has been accomplished without the backing
of the real core filesystem people.
If block layer integrity was enough, there wouldn't have been a need
for fs-verity. Even fs-verity is limited to read only filesystems,
which makes validating file integrity so much easier. From the
beginning, we've said that fs-verity signatures should be included in
the measurement list. (I thought someone signed on to add that support
to IMA, but have not yet seen anything.)
Going forward I see a lot of what we've accomplished being incorporated
into the filesystems. When IMA will be limited to defining a system
wide policy, I'll have completed my job.
Mimi
> I've got to say the least attractive thing
> about separation is the fact that you now both have a policy parser.
> You've tried to differentiate yours by making it more Kconfig
> based, but policy has a way of becoming user space supplied because
> the distros hate config options, so I think you're going to end up
> with a policy parser very like IMAs.