On Thu, 2018-12-20 at 09:55 -0500, Mimi Zohar wrote: > On Wed, 2018-12-19 at 14:08 -0800, James Bottomley wrote: > > > > For portable signatures, to bind the file metadata with the file > > > data, we've replaced the inode number and generation, with the > > > "security.ima" xattr. Do we want this requirement/limitation for > > > overlays? > > > > Well, that's my question, yes. I think there's a reasonable case > > for it, but I was wondering what value the inode number and > > generation brings. Is there some reason to bind the EVM signature > > to a more mutable file container (which is what inum/generation > > provide) rather than a hard hash of file content (which is what the > > ima xattr provides)? > > As only files in the IMA policy are labeled with security.ima, to > protect other files and directories, requires including the inode > number, generation and the UUID. OK, so you want to protect the container (essentially file name and place in the tree) not the contents? In which case, as Amir said, you need to be using the filehandle got from something like exportfs_encode_inode_fh(). That's guaranteed to be an immutable and stable representative of the container not the contents. > > > The existing EVM portable signature is an asymmetric algorithm > > > based signature. Would we define a "portable" HMAC? > > > > Well, a signature is just an encryption of a hash. Whether you do > > HMAC with symmetric key or RSA/EC with an asymmetric one is more an > > operational question. HMAC is certainly much faster but EVM only > > has a single hmac key which is problematic for the > > containers. Without a use case I can't really say. Instinct tells > > me asymmetric is more suitable to the container use case, but > > that's really just a guess. > > One of the differences between the EVM portable signature type and > the original signature type is that the portable signatures aren't > replaced with an HMAC. They're considered portable & immutable. > > Adding kernel support for signing mutable files using an asymmetric > key is going to blur the lines between mutable/immutable files. So don't do that ... have an additional type that simply doesn't include the inode/generation (or move to a v2 that uses the filehandle instead). James
