On 08/04/2020 12:19, Tushar Sugandhi wrote: > The goals of the kernel integrity subsystem are to detect if files have > been accidentally or maliciously altered, both remotely and locally, > appraise a file's measurement against a "good" value stored as an > extended attribute, and enforce local file integrity [1]. > > To achieve these goals, IMA subsystem measures several in-memory > constructs and files. > > We propose to measure constructs in dm-crypt and selinux to further > enhance measuring capabilities of IMA. ... > Proposal: > --------- > A. Measuring dmcrypt constructs: > We can add an IMA hook in crypt_ctr() present in > drivers/md/dm-crypt.c, so that IMA can start measuring the status of > various dm-crypt targets (represented by crypt_target struct - also > defined in dm-crypt.c). Hi, I do not think you should just cherry-pick dm-crypt here. What about other device-mapper targets? Apparently, dm-verity or dm-integrity are obvious candidates too. But device-mapper logic is based on stacking devices, so in generic case (not just in some very special embedded configuration) you need to measure the whole stack of devices. (Just imagine a target stacked below dm-crypt that decrypts the device or so. :-) Moreover, dm-crypt allows some specific actions like wiping and reloading of the encryption key through device-mapper dm-crypt message. If you check parameter only in crypt_ctr, this message path must be disabled, basically crippling dm-crypt functionality (it is intended to wipe key in-memory during hw suspend). IMO if you want implement something like IMA measurement, I think you should implement it in device-mapper core, and provide support for all targets. I guess some new target specific callback is needed and some flags that could enforce/disable stacking if a IMA measurement is in place etc. Milan
