On Fri, 2011-07-01 at 10:34 -0400, Mimi Zohar wrote: > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
