On Fri, 2017-09-29 at 13:09 -0700, Matthew Garrett wrote: > 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? A copy of the file could exist with a valid hmac on the system with different security xattrs. Without the inode/uuid, the xattrs could be cut & pasted. Ok, I agree this would be less of an issue for security.evm signatures, since the signatures are not being generated on the locally running system. Mimi