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

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.

I think what the above is trying to to is to expose is an IMA
limitation that the new LSM fixes.  I think what it meant to say is
that IMA uses xattrs to store the signature data which is the "metadata
dependency".  However, it overlooks the fact that IMA can use appended
signatures as well, which have no metadata dependency, so I'm not sure
I've helped you understand why this is different from IMA.

Perhaps a more convincing argument is that IMA hooks into various
filesystem "gates" to perform integrity checks (file read and file
execute being the most obvious).  This LSM wants additional gates
within device mapper itself that IMA currently doesn't hook into.

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?

James