Re: [RFC PATCH v7 12/16] fsverity|security: add security hooks to fsverity digest and signature

> > 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?

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