Open pohly opened 8 years ago
Yep, that's probably it. From meta-intel-iot-security/meta-integrity/recipes-kernel/linux/linux-%.bbappend:
# This patch is necessary to unpack archives with security.ima xattr
# such that security.ima is taken from the archive. If the policy
# allows hashing, unpatched kernels (at least up to 4.3) will replace
# a signed hash in security.ima with a locally computed hash.
#
# Note that only bsdtar/libarchive are known to work; GNU tar sets
# the security.ima on an empty file and the tries re-opening it for
# writing its content, which then fails due to the IMA hash mismatch.
#
# Patches are potentially kernel version specific. Only some tested kernel versions
# are supported here. Currently they all work with the same patch file, though.
IMA_EVM_SETATTR_PATCH_4.1.18 = "file://0001-ima-fix-ima_inode_post_setattr.patch \
file://0002-ima-add-support-for-creating-files-using-the-mknodat.patch \
"
IMA_EVM_SETATTR_PATCH_4.1.15 = "file://0001-ima-fix-ima_inode_post_setattr.patch \
file://0002-ima-add-support-for-creating-files-using-the-mknodat.patch \
"
IMA_EVM_SETATTR_PATCH_4.4.3 = "file://0001-ima-fix-ima_inode_post_setattr.patch \
file://0002-ima-add-support-for-creating-files-using-the-mknodat.patch \
"
IMA_EVM_SETATTR_PATCH_4.4.14 = "file://0001-ima-fix-ima_inode_post_setattr.patch \
file://0002-ima-add-support-for-creating-files-using-the-mknodat.patch \
"
We don't have an entry for the current 4.4.20 kernel.
This is going to break again and again each time the kernel gets a minor version bump. I'm not sure what the right solution is - should we enable the patch by default and only blacklist the kernels for which it is not needed?
Yep, it's not the first time we bump into an outdated kernel patch set. I'd second applying the IMA kernel patches by default.
Updating intel-corei7-64 build #505 to #507 fails even when using the Smack transmute workaround:
That entry corresponds to:
This already occurred for updates #505->#506 and also affects #506->#507.
Comparing the attributes of that local copy under /var/lib/swupd against the corresponding file in a running #5060 did not reveal any obvious attribute mismatches. Local copy:
There's no getfattr in my #505 image (ostro-image-swupd, not ostro-image-swupd-dev), so I can't check IMA xattrs.
For #506->#507 it complains about /bin/arping.
That's the smoking gun: the security.ima was locally hashed while it should be the signed hash from the archive.
@rojkov wasn't there some kind of kernel patch that was needed to ensure that bsdtar unpacks the security.ima correctly? Have we lost that patch again?