On 6/13/2019 10:04 AM, Janne Karhunen wrote:
On Thu, Jun 13, 2019 at 10:50 AM Roberto Sassu <roberto.sassu@xxxxxxxxxx> wrote:
Would the appraise actually need any changes, just keep the
IMA_NEW_FILE in ima_check_last_writer()? Of course it's not that easy
(it never is) as the iint could go away and things like that, but with
some tweaks?
I think the problem would be that the code that sets the status to
INTEGRITY_PASS is not executed, because the file gets security.ima after
the first write.
We have a patchset coming shortly that starts tracking the inode
changes as we go, so first time we fix it is when the file is created
before it has any content (!);
diff --git a/security/integrity/ima/ima_appraise.c
b/security/integrity/ima/ima_appraise.c
index 5fb7127bbe68..da4f0afe0348 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -236,8 +236,10 @@ int ima_appraise_measurement(enum ima_hooks func,
iint->flags |= IMA_NEW_FILE;
if ((iint->flags & IMA_NEW_FILE) &&
(!(iint->flags & IMA_DIGSIG_REQUIRED) ||
- (inode->i_size == 0)))
+ (inode->i_size == 0))) {
+ ima_fix_xattr(dentry, iint);
status = INTEGRITY_PASS;
Some time ago I developed this patch:
http://kernsec.org/pipermail/linux-security-module-archive/2017-November/004569.html
Since the appraisal flags are not cleared, ima_appraise_measurement() is
not executed again and the problem with EVM does not arise.
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
