linux-kernel - Re: [PATCH v7 00/16] EVM

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-next>] [day] [month] [year] [list]

Message-ID: <1309530873.3245.23.camel@localhost.localdomain>
Date:	Fri, 01 Jul 2011 10:34:33 -0400
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Kyle Moffett <kyle@...fetthome.net>
Cc:	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	James Morris <jmorris@...ei.org>,
	David Safford <safford@...son.ibm.com>
Subject: Re: [PATCH v7 00/16] EVM

On Thu, 2011-06-30 at 18:31 -0400, Kyle Moffett wrote:

> The problem is that you are assuming that a large chunk of filesystem
> code is capable of properly and securely handling untrusted and
> malicious
> content.  Historically filesystem drivers are NOT capable of handling
> such things, as evidenced by the large number of bugs that tools such
> as
> fsfuzzer tend to trigger.  If you want to use IMA as-designed then you
> need to perform a relatively extensive audit of filesystem and fsck
> code.
> 
> Furthermore, even when the filesystem does not have any security
> issues
> itself, you are assuming that intentionally malicious data-aliasing
> between "trusted" and "untrusted" files can have no potential security
> implications.  You should look at the prevalence of simple stupid
> "/tmp"
> symlink attacks for more counter-examples there.
> 
> In addition, IMA relies on the underlying attribute and data caching
> properties of the VFS, which won't hold true for intentionally
> malicious
> corrupted filesystems.  It effectively assumes that writing data or
> metadata for one file will not invalidate the cached data or metadata
> for
> another which is blatantly false when filesystem extents overlap each
> other.
> 
> Overall, the IMA architecture assumes that if it loads and validates
> the
> file data or metadata that it cannot be changed except through a
> kernel
> access to that particular inode.  For a corrupted filesystem that is
> absolutely untrue.
> 
> Cheers,
> Kyle Moffett

You've brought up a number of interesting scenarios, which I appreciate.
I will definitely take a closer look at fsfuzzer. It might be a good
starting point for an EVM/IMA-appraisal LTP testsuite. The bottom line,
as I said previously, is that EVM/IMA-appraisal doesn't need to prevent
these things from occurring.  It just needs to be able to detect them.
Caching the integrity verification results is a performance issue, be it
an important one.

Currently the integrity verification results are reset when the file
data or metadata changes and removed on __fput().  Based on your
scenarios, I am looking to see if there might be additional situations
where the verification results need to be reset.

thanks,

Mimi

--
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/