On Tue, 2020-08-04 at 09:07 -0700, Deven Bowers wrote:

On 8/2/2020 9:43 AM, James Bottomley wrote:

quoted

On Sun, 2020-08-02 at 16:31 +0200, Pavel Machek wrote:

quoted

On Sun 2020-08-02 10:03:00, Sasha Levin wrote:

quoted

On Sun, Aug 02, 2020 at 01:55:45PM +0200, Pavel Machek wrote:

quoted

Hi!

quoted

IPE is a Linux Security Module which allows for a
configurable policy to enforce integrity requirements on
the whole system. It attempts to solve the issue of Code
Integrity: that any code being executed (or files being
read), are identical to the version that was built by a
trusted source.

How is that different from security/integrity/ima?

Maybe if you would have read the cover letter all the way down
to the 5th paragraph which explains how IPE is different from
IMA we could avoided this mail exchange...

"
IPE differs from other LSMs which provide integrity checking (for
instance, IMA), as it has no dependency on the filesystem
metadata itself.
The attributes that IPE checks are deterministic properties that
exist solely in the kernel. Additionally, IPE provides no
additional mechanisms of verifying these files (e.g. IMA
Signatures) - all of the attributes of verifying files are
existing features within the kernel, such as dm-verity
or fsverity.
"

That is not really helpful.

Perhaps I can explain (and re-word this paragraph) a bit better.

As James indicates, IPE does try to close the gap of the IMA
limitation with xattr. I honestly wasn’t familiar with the appended
signatures, which seems fine.

Regardless, this isn’t the larger benefit that IPE provides. The
larger benefit of this is how IPE separates _mechanisms_ (properties)
to enforce integrity requirements, from _policy_. The LSM provides
policy, while things like dm-verity provide mechanism.

Colour me confused here, but I thought that's exactly what IMA does. 
The mechanism is the gates and the policy is simply a list of rules
which are applied when a gate is triggered.  The policy necessarily has
to be tailored to the information available at the gate (so the bprm
exec gate knows filesystem things like the inode for instance) but the
whole thing looks very extensible.

So to speak, IPE acts as the glue for other mechanisms to leverage a
customizable, system-wide policy to enforce. While this initial
patchset only onboards dm-verity, there’s also potential for MAC
labels, fs-verity, authenticated BTRFS, dm-integrity, etc. IPE
leverages existing systems in the kernel, while IMA uses its own.

Is this about who does the measurement?  I think there's no reason at
all why IMA can't leverage existing measurements, it's just nothing to
leverage existed when it was created.

Another difference is the general coverage. IMA has some difficulties
in covering mprotect[1], IPE doesn’t (the MAP_ANONYMOUS indicated by
Jann in that thread would be denied as the file struct would be null,
with IPE’s current set of supported mechanisms. mprotect would
continue to function as expected if you change to PROT_EXEC).

I don't really think a debate over who does what and why is productive
at this stage.  I just note that IMA policy could be updated to deny
MAP_ANONYMOUS, but no-one's asked for that (probably because of the
huge application breakage that would ensue).  The policy is a product
of the use case and the current use case for IMA is working with
existing filesystem semantics.

quoted

Perhaps the big question is: If we used the existing IMA appended
signature for detached signatures (effectively becoming the
"properties" referred to in the cover letter) and hooked IMA into
device mapper using additional policy terms, would that satisfy all
the requirements this new LSM has?

Well, Mimi, what do you think? Should we integrate all the features
of IPE into IMA, or do you think they are sufficiently different in
architecture that it would be worth it to keep the code base in
separate LSMs?

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.

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

James