swupd: hash mismatch on regular file

[pohly]

Updating intel-corei7-64 build #505 to #507 fails even when using the Smack transmute workaround:

rm -rf /var/lib/swupd/ && mkdir /var/lib/swupd/ && chsmack -T /var/lib/swupd
swupd update -F 3 https://download.ostroproject.org/updates/ostro-os/builds/intel-corei7-64/ostro-image-swupd/
=>
swupd-client software update 3.6.0
   Copyright (C) 2012-2016 Intel Corporation

Attempting to download version string to memory
Update started.
Querying server version.
Attempting to download version string to memory
Preparing to update from 5050 to 5070
Querying current manifest.
Querying server manifest.
Warning: hash check failed for Manifest.os-core
Warning: hash check failed for Manifest.os-core
Warning: hash check failed for Manifest.os-core
Running script 'Pre-update'
Downloading os-core pack for version 5070

Statistics for going from version 5050 to version 5070:

    changed manifests : 4
    new manifests     : 0
    deleted manifests : 0

    changed files     : 385
    new files         : 32
    deleted files     : 0

Starting download of remaining update content. This may take a while...
Error: File content hash mismatch for /var/lib/swupd/staged/624d842a6787c512a429661f01317ab223c3ccd9e1b8ef2f988444cbc97374c3 (bad server data?)

That entry corresponds to:

# grep 624d842a6787c512a429661f01317ab223c3ccd9e1b8ef2f988444cbc97374c3 /var/lib/swupd/5070/Manifest.os-core
F...    624d842a6787c512a429661f01317ab223c3ccd9e1b8ef2f988444cbc97374c3    5070    /bin/tracepath

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:

# ls -l /var/lib/swupd/staged/624d842a6787c512a429661f01317ab223c3ccd9e1b8ef2f988444cbc97374c3
-rwxr-xr-x    1 root     root         16896 Sep 30 04:52 /var/lib/swupd/staged/624d842a6787c512a429661f01317ab223c3ccd9e1b8ef2f988444cbc97374c3
root@intel-corei7-64:~# chsmack /var/lib/swupd/staged/624d842a6787c512a429661f01317ab223c3ccd9e1b8ef2f988444cbc97374c3
/var/lib/swupd/staged/624d842a6787c512a429661f01317ab223c3ccd9e1b8ef2f988444cbc97374c3 access="_"

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.

# getfattr -d -m . /var/lib/swupd/staged/4782b62a655d60a7e79980cc1208ab73c8e7cf7ca4869be8a64798183a14bab5
getfattr: Removing leading '/' from absolute path names
# file: var/lib/swupd/staged/4782b62a655d60a7e79980cc1208ab73c8e7cf7ca4869be8a64798183a14bab5
security.SMACK64="_"
security.ima=0sAeBBIxKgArnntaLz2r3YRmPmRgDM

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?

[pohly]

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?

[rojkov]

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.