On Wed, 2018-12-19 at 13:15 -0500, Mimi Zohar wrote:
> On Wed, 2018-12-19 at 08:56 -0800, James Bottomley wrote:
> > On Wed, 2018-12-19 at 10:39 -0500, Mimi Zohar wrote:
> > > Confirmed, in linux-4.18.y d_backing_inode returns the real
> > > i_ino, but newer kernels do not.
> >
> > Just so we're clear, this isn't an issue with d_backing_inode(),
> > which hasn't changed since its introduction in 2015 and which
> > always returns dentry->d_inode (it was originally a helper for
> > unionfs which got merged even though unionfs didn't, which makes it
> > and the comment about upper/lower totally misleading). The problem
> > is that overlayfs has changed the inode it places into d_inode.
> >
> > > This is a problem for EVM as the i_ino is included in the HMAC
> > > calculation.
> >
> > Isn't the solution always to use portable signatures for
> > containers?
> > It's problematic to include inode and generation with an overlay
> > because if you change the metadata it gets copied up => new inode
> > number and generation on the upper filesystem but if we were always
> > using the underlying inode number and generation, the signature
> > would then be wrong on the copied up file.
> >
> > At base, most container images are sets of tar files, which are not
> > inode number preserving anyway, so even if we find a convoluted way
> > to fix the above, the EVM signature has to be portable because
> > otherwise its always wrong for container images.
>
> Ignaz's use case was mutable files, not immutable files with file
> signatures.
The word "mutable" is problematic in terms of overlays. Only the upper
layer is mutable, so if your EVM signed file is anywhere other than in
the top layer it's technically immutable. What you get when you mutate
it is a copy up. the VFS guarantee is that inode numbers are stable
only for the current mount and may change on a remount. Most disk
backed filesystems have inode numbers encoded in their on disk inodes,
which is why they have far more stability than the simple VFS
requirement, but some filesystems can't have long term stable inode
numbers. We recognise this problem in EVM with so called "portable
signatures" that don't include the inode number and generation.
I'm interested in discussing two points
1. Can we actually come up with semantics where the EVM signature is
always valid for overlays?
2. If the answer to 1. is "no" should we not always use portable
signatures for overlay cases?
I think there are a load of nasty corner cases in 1. that make 2. far
more preferable, but perhaps we can begin with the use case that
requires non-portable signatures with overlays, because I don't think
I've heard it yet.
> Prior to 4.19, EVM was calculating and verifying the file
> HMAC properly. With 4.19, it stopped working because the i_ino used
> in calculating the HMAC value stored in security.evm, is not the same
> when verifying the HMAC value.
Yes, but the same thing would happen on cifs or NFS or any other
filesystem that constructs inode numbers on the fly. If we're not
proposing trying to fix them, why fix overlayfs?
James
