On 10/27/2021 8:48 PM, Eric Biggers wrote:
On Tue, Oct 26, 2021 at 12:03:53PM -0700, Deven Bowers wrote:
The proposed LSM (IPE) of this series will be the only one to need
this information at the moment. IPE’s goal is to have provide
trust-based access control. Trust and Integrity are tied together,
as you cannot prove trust without proving integrity.
I think you mean authenticity, not integrity?
I’ve heard a lot of people use these terms in overloaded ways.
If we’re working with the definition of authenticity being
“the property that a resource was _actually_ sent/created by a
party”, and integrity being “the property that a resource was not
modified from a point of time”, then yes. Though the statement isn’t
false, though, because you’d need to prove integrity in the process of
proving authenticity.
If not, could you clarify what you mean by authenticity and integrity,
so that we can use consistent definitions?
In cryptography, integrity normally means knowing whether data has been
non-maliciously changed, while authenticity means knowing whether data is from a
particular source, which implies knowing whether it has been changed at all
(whether maliciously or not). Consider that there are "Message Authentication
Codes" (MACs) and "Authenticated Encryption", not "Message Integrity Codes" and
"Intact Encryption".
Unfortunately lots of people do overload "integrity" to mean authenticity, so
you're not alone. But it's confusing, so if you're going to do that then please
make sure to clearly explain what you mean.
Also how does this differ from IMA? I know that IMA doesn't support fs-verity
file hashes, but that could be changed. Why not extend IMA to cover your use
case(s)?
We looked at extending IMA to cover our requirements extensively the past
year
based on feedback the last time I posted these patches. We implemented a
prototype that had half of our requirements, but found it resulted in a
large change list that would result in a large amount of pain in respect
to maintenance, in addition to other more architectural concerns about the
implementation. We weren’t convinced it was the correct direction, for our
needs.
There was a presentation done at LSS 2021 around this prototype done by my
colleague, Fan, who authored this patch and implemented the aforementioned
prototype.
In general, IMA provides a whole suite of amazing functionality when it
comes to everything integrity, as the fs-verity documentation states
itself:
IMA specifies a system-wide policy that specifies which
files are hashed and what to do with those hashes, such
as log them, authenticate them, or add them to a
measurement list.
Instead, IPE provides a fine-tuned way to _only_ enforce an access control
policy to these files based on the defined trust requirements in the policy,
under various contexts, (you might have different requirements for what
executes in a general purpose, versus loadable kernel modules, for example).
It will never provide bother to log, measure, or revalidate these hashes
because
that’s not its purpose. This is why it belongs at the LSM layer instead of
the
integrity subsystem layer, as it is providing access control based on a
policy,
versus providing deep integrations with the actual integrity claim.
IPE is trying to be agnostic to how precisely “trust” is provided, as
opposed to be deeply integrated into the mechanism that provides
“trust”.
IMA doesn't require logging or "measuring" hashes, though. Those are just some
of its supported features. And I thought the IMA developers were planning to
add support for fs-verity hashes, and that it wouldn't require an entirely new
architecture to do so.
Anyway, while it does sound to me like you're duplicating IMA, I don't really
have a horse in this race, and I defer to the IMA developers on this. I trust
that you've been engaging with them? This patchset isn't even Cc'ed to
linux-integrity, so it's unclear that's been happening.
That was entirely my mistake. Mimi and the linux-integrity list was CC'd
on previous
versions (Roberto actually added the list to his responses) - when I was
reconstructing
the To: line with get-maintainers.pl, the list didn't pop up and I did
not remember to
add it manually. I've corrected my mailing script to re-add them again.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
