linux-kernel - Re: [PATCH] ima: ecryptfs fix imbalance message

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AC3AC33.1020907@linux.vnet.ibm.com>
Date:	Wed, 30 Sep 2009 14:06:27 -0500
From:	Tyler Hicks <tyhicks@...ux.vnet.ibm.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
CC:	linux-kernel@...r.kernel.org, Eric Paris <eparis@...hat.com>,
	Dustin Kirkland <kirkland@...onical.com>,
	James Morris <jmorris@...ei.org>,
	David Safford <safford@...son.ibm.com>, stable@...nel.org,
	Mimi Zohar <zohar@...ibm.com>
Subject: Re: [PATCH] ima: ecryptfs fix imbalance message

On 09/29/2009 04:08 PM, Mimi Zohar wrote:
> The underlying files are measured. Update the counters to get rid of
> the ecryptfs imbalance message. (http://bugzilla.redhat.com/519737)
> 
> Reported-by: Sachin Garg <ascii79@...il.com>
> Cc: stable@...nel.org
> Signed-off-by: Mimi Zohar <zohar@...ibm.com>
> ---
>  fs/ecryptfs/main.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/ecryptfs/main.c b/fs/ecryptfs/main.c
> index 9f0aa98..177e61e 100644
> --- a/fs/ecryptfs/main.c
> +++ b/fs/ecryptfs/main.c
> @@ -35,6 +35,7 @@
>  #include <linux/key.h>
>  #include <linux/parser.h>
>  #include <linux/fs_stack.h>
> +#include <linux/ima.h>
>  #include "ecryptfs_kernel.h"
> 
>  /**
> @@ -135,7 +136,8 @@ int ecryptfs_init_persistent_file(struct dentry *ecryptfs_dentry)
>  			       "rc = [%d]\n", lower_dentry, lower_mnt, rc);
>  			rc = PTR_ERR(inode_info->lower_file);
>  			inode_info->lower_file = NULL;
> -		}
> +		} else
> +			ima_counts_get(inode_info->lower_file);
>  	}
>  	mutex_unlock(&inode_info->lower_file_mutex);
>  	return rc;

Hi Mimi - I can't think of why we would want to measure the underlying
files.  The file contents are encrypted with a randomly generated key
and there is eCryptfs metadata stored in the first 8K of the underlying
file.  If you have two eCryptfs mounts, using the same key, and copy the
same file into both mount points, you'll end up with two entirely
different underlying files.

Taking a closer look at IMA is still on my TODO list, so I could be
missing something obvious.  The upper (decrypted) file is being
measured, right?

For performance and the reason mentioned above, it seems like the proper
fix is to only measure the upper file.  What do you think?

Tyler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/