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
On Fri, 2011-07-01 at 10:34 -0400, Mimi Zohar wrote:
On Thu, 2011-06-30 at 18:31 -0400, Kyle Moffett wrote:
quoted
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.
I forgot to mention that the IMA-appraisal-directory extension,
discussed in the Integrity whitepaper, will also address some of the
concerns you raised.
thanks,
Mimi