lkml.org 
[lkml]   [2011]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v7 00/16] EVM
    From
    Date
    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



    \
     
     \ /
      Last update: 2011-07-01 16:37    [W:0.025 / U:242.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site