quoted

quoted

There is another problem, when delayed copy is used. The content comes
from one source, metadata from another.

I initially created test-file-lower on the lower directory
(overlayfs/data), before mounting overlayfs. After mount on
overlayfs/mnt:

# getfattr -m - -e hex -d overlayfs/mnt/test-file-lower
# file: overlayfs/mnt/test-file-lower
security.evm=0x02c86ec91a4c0cf024537fd24347b780b90973402e
security.ima=0x0404f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
security.selinux=0x73797374656d5f753a6f626a6563745f723a756e6c6162656c65645f743a733000

# chcon -t unconfined_t overlayfs/mnt/test-file-lower

After this, IMA creates an empty file in the upper directory
(overlayfs/root/data), and writes security.ima at file close.
Unfortunately, this is what is presented from overlayfs, which is not
in sync with the content.

# getfattr -m - -e hex -d overlayfs/mnt/test-file-lower
# file: overlayfs/mnt/test-file-lower
security.evm=0x021d71e7df78c36745e3b651ce29cb9f47dc301248
security.ima=0x04048855508aade16ec573d21e6a485dfd0a7624085c1a14b5ecdd6485de0c6839a4
security.selinux=0x73797374656d5f753a6f626a6563745f723a756e636f6e66696e65645f743a733000

# sha256sum overlayfs/mnt/test-file-lower
f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2  overlayfs/mnt/test-file-lower

# sha256sum overlayfs/root/data/test-file-lower
8855508aade16ec573d21e6a485dfd0a7624085c1a14b5ecdd6485de0c6839a4  overlayfs/root/data/test-file-lower (upperdir)

We would need to use the lower security.ima until the copy is made, but
at the same time we need to keep the upper valid (with all xattrs) so
that IMA can update the next time overlayfs requests that.

Yap.

As Seth wrote, overlayfs is a combination of upper and lower.
The information that IMA needs should be accessible from either lower
or upper, but sometimes we will need to make the right choice.

The case of security.ima is similar to that of st_blocks -
it is a data-related metadata, so it needs to be taken from the lowerdata inode
(not even the lower inode). See example of getting STATX_BLOCKS
in ovl_getattr().

I would accept a patch that special cases security.ima in ovl_xattr_get()
and gets it from ovl_i_path_lowerdata(), which would need to be
factored out of ovl_path_lowerdata().

I would also accept filtering out security.{ima,evm} from

But I would only accept it if I know that IMA is not trying to write the
security.ima xattr when closing an overlayfs file, only when closing the
real underlying upper file.

I don't see how that would be possible.  As far as I'm aware, the
correlation is between the overlay and the underlying lower/uppper
file, not the other way around.  How could a close on the underlying
file trigger IMA on an overlay file?

Well, you are right. it cannot.

What I meant is that close of overlayfs file should NOT open and read
the overlayfs file and recalculate security.ima to store in overlayfs inode
because close of overlayfs file will follow a close of the upper file that
should recalculate and store security.ima in the upper inode.

It is possible that a close of an overlayfs file will update the security
state of the overlayfs inode by copying the security state from the
upper inode.

But then again, I could be misunderstanding the IMA workflows
and it could be more complicated than I try to present it.
This is the reason that I requested the documentation of how
IMA+overlayfs is *expected* to work.

Thanks,
Amir.