On December 1, 2015 11:03:32 PM GMT+02:00, David Howells <dhowe...@redhat.com> wrote: >Petko Manolov <pet...@mip-labs.com> wrote: > >> 0) does keyrings keep a timestamp when created or last updated? >David? > >No. > >> 0) is crucial. If there is no such thing as "time of the last >update" for >> keyrings i guess we'll either have to implement it or use another >mechanism >> to get similar result. > >You haven't said why you want it? Update what? > >David
Once a file has been hashed, IMA keeps this value in a cache in order to avoid doing the same thing in the future. This used to work properly until we introduced a blacklist keyring. It is now possible the key that signed a file with already calculated and cached hash to land in the said keyring. It would be incorrect behavior to allow the requested operation. One way to deal with this situation is to invalidate the whole iint cache when a key enters the blacklist keyring. Far from optimal. Another way is to extend the iint structure with a timestamp field that is updated when the hash is calculated. We could then compare this time against the last time the blacklist keyring was updated. If newer then all is well. If the hash was calculated earlier we invalidate this entry and do all checks anew. The third option may be to compare the IDs of the blacklisted key(s) against the one that signed the file and base the decision on this. This isn't a bad one either but i am not sure about key ID collisions. Petko -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
