On Mon, Oct 9, 2017 at 10:51 AM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: >> >> I'm not really clear on what attacks are prevented by using the inode >> >> number. If I'm able to preserve all the other security metadata when >> >> copying a file, I can just create a hardlink to the original instead >> >> and have the same outcome. >> > >> > The issue is the ability of having different security metadata, not >> > the same security metadata. (I need to refresh my memory as to hard >> > links, and whether they can have different security metadata.) >> >> If the security metadata is different then copying another >> security.evm will fail, surely? > > The assumption here is that security.ima exists and is included in the > HMAC calculation. For files which are not included in the IMA policy, > the only thing binding the file data and metadata is the i_ino and > uuid. Ok, that makes sense. But for cases where we do have security.ima, the inode doesn't seem to provide additional security but does make deployment more difficult. Does supporting this use case seem reasonable?
