On Mon, 2017-10-09 at 10:59 -0700, Matthew Garrett wrote: > 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? Yes!
