I think moving away from the idea that measuring "critical" data should
be limited to LSMs, will clarify this.
Are you suggesting that instead of calling the hooks LSM_STATE and LSM_POLICY, we should keep it more generic so that it can be utilized by any subsystem to measure their "critical data"?
Policy, state, history or whim, it should be up to the security module
to determine what data it cares about, and how it should be measured.
Smack does not keep its policy in a single blob of data, it uses lists
which can be modified at will. Your definition of the behavior for
LSM_POLICY wouldn't work for Smack. That doesn't mean that there isn't
a viable way to measure the Smack policy, it just means that IMA isn't
the place for it. If SELinux wants its data measured, SELinux should be
providing the mechanism to do it.
I guess that I'm agreeing with you in part. If you want a generic measurement
of "critical data", you don't need to assign a type to it, you have the
caller (a security module, a device driver or whatever) identify itself and
how it is going to deal with the data. That's very different from what you've
done to date.
Agree.
Like Stephen had stated earlier, the reason we kept separate hooks (STATE and POLICY) is because the data for state is usually small and therefore we measure the entire data. Whereas, policy data is usually quite large (a few MB) and hence we measure a hash of the policy.
SELinux should determine how it wants its data measured.
SELinux, not IMA, should determine if some "critical data"
be measured in total, by its hash or as a count of policy
rules. It would be handy for IMA to supply functions to do
data blobs and hashes, but it should be up to the caller to
decide if they meet their needs.