On Fri, Sep 29, 2017 at 1:01 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2017-09-29 at 12:17 -0700, Matthew Garrett wrote: >> I'm arguing that (for our case at least) the only way we can use IMA >> is to rely on using a digital signature - we can either have that >> digital signature be in security.ima, or we can have it in >> security.evm. Since we need that signature in any case, we derive no >> benefit from having security.evm be an hmac - our two reasonable >> choices are: >> >> 1) security.ima as a digital signature, security.evm as an hmac >> 2) security.ima as a hash, security.evm as a digital signature > > There's a major difference between security.ima containing a file hash > vs a signature. A signature, assuming the file_check hook is in > policy, prevents the file from being modified, making the file > "immutable". But the same is effectively true if security.evm is a digital signature and there's no symmetric key? For what we want to do (ensure that executables that are allowed to run with elevated privileges haven't been tampered with), that's completely ok. >> 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? > Originally the UUID was not included in the HMAC calculation. Perhaps > the patch description of commit 74de668 "evm: add file system uuid to > EVM hmac" will help clarify the reasoning for including the inode and > uuid in the hmac calculation. Not really - if you're not crossing a filesystem boundary then you're still able to just create a hardlink.
