Re: EVM: Permission denied with overlayfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> > 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.

Mimi




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux