On 3/25/22 08:31, Mimi Zohar wrote:
On Mon, 2022-03-21 at 09:10 -0400, Stefan Berger wrote:
On 3/18/22 14:21, Mimi Zohar wrote:
IMA may verify a file's integrity against a "good" value stored in the
'security.ima' xattr or as an appended signature, based on policy. When
the "good value" is stored in the xattr, the xattr may contain a file
hash or signature. In either case, the "good" value is preceded by a
header. The first byte of the xattr header indicates the type of data
- hash, signature - stored in the xattr. To support storing fs-verity
signatures in the 'security.ima' xattr requires further differentiating
the fs-verity signature from the existing IMA signature.
In addition the signatures stored in 'security.ima' xattr, need to be
disambiguated. Instead of directly signing the fs-verity digest, a new
signature version 3 is defined as the hash of the ima_file_id structure,
which identifies the type of signature and the digest.
Would it not be enough to just differentiat by the type of signature
rather than also bumping the version? It's still signature_v2_hdr but a
new type IMA_VERITY_DIGSIG is introduced there that shoud be sufficient
to indicate that a different method for calculating the hash is to be
used than for anything that existed before? sigv3 would then become the
more obvious veriftysig... ?
One of Eric's concerns was that, "an attacker (who controls the file's
contents and IMA xattr) [could] replace the file with one with a
Reference:
https://lore.kernel.org/linux-integrity/20220126000658.138345-1-zohar@xxxxxxxxxxxxx/T/#m8929fa29fbdfc875dbf5f384a4c082d303d2040e
This seem to describe the root user. A restrictions of root's power
maybe that root may not have access to the file signing key use on the
local system... ?
differrent content and still be able to pass the IMA check." His
Is this a scenario of concern? : /usr/bin/foobar is signed by verity and
there's a rule in the IMA policy that would appraise this file. Can root
now remove /usr/bin/foobar and copy the regularly signed /usr/bin/bash
to /usr/bin/foobar along with bash's security.ima and have it execute
either since there's no appraise rule covering non-fsverity signatures
or due to a rule that covers non-fsverity signatures?
Since the signature header of security.ima is not signed root could also
just rewrite the header and modify the signature type (and also version)
and circumvent appraisal rules specific to fsverity.
solution was to only allow one signature version on a running system.
For the complete description of the attack, refer to Eric's comments on
v3.
I am trying to figure out a concrete scenario that one has to defend
against what seems to be the power of the root user. A more concrete
example may be helpful.
Instead of only allowing one signature version on a running system,
subsequent versions of this patch set addressed his concern, by
limiting the signature version based on policy.
