Re: [PATCH 1/1] fiemap: move i_op->fiemap() locking to the ioctl_fiemap()

[Dave Chinner <david@fromorbit.com>]

On Wed, Sep 26, 2012 at 11:22:14AM +0300, Kasatkin, Dmitry wrote:
> On Tue, Sep 25, 2012 at 4:56 AM, Dave Chinner <david@fromorbit.com> wrote:
> > On Mon, Sep 24, 2012 at 02:28:15PM +0300, Kasatkin, Dmitry wrote:
> >> On Mon, Sep 24, 2012 at 12:18 PM, Dave Chinner <david@fromorbit.com> wrote:
> >> > On Mon, Sep 24, 2012 at 11:13:30AM +0300, Kasatkin, Dmitry wrote:
> >> >> One of the patches we are working on now would like to use extent map
> >> >> information to prevent certain attack.
> >> >
> >> > I'm not a mind reader. What attack may that be?
> >>
> >> That is a simple attack of modifying inode block map so that different
> >> files points to the same blocks.
> >> FSCK calls them "multiply claimed blocks"...
> >
> > Just force users to run fsck before mounting?
> 
> Not good for mobile device from boot time point of view.

Not good for a server with a 100TB filesystem either.

> > Better question: why won't file data integrity checks detect such
> > errors? Data integrity checks will only pass if the duplicate block
> > has identical data, or someone is clever enough to find an existing
> > block on disk that magically causes a hash collision. Finding a hash
> > collision already on disk is so unlikely that someone who has the
> > access and ability to calculate a hash collision will simply
> > overwrite the file contents directly....
> 
> No.. that is not about a collision...

It's just one possibility the moment you start talking about offline
modification of a block device.

> Possible attack to IMA - I have done it...
> 
> 1. make a file copy.
>     now we have 2 files with the same data and hash.
> 2. modify block map that second file points to the blocks of first...
>     IMA verification succeeds, because content is the same
> 3. write some data to second file...
>     it will also change content of first file.

And so IMA data verification will then fail on the first file when
it is read, and then you can go and find the problem causing the
verification error. I fail to see the problem at this point.

> 4. create some low memory pressure to force kernel to drop pages.
> 5. open first file again.
>     pages will be loaded again, but now verified by IMA, because inode
>     is still in the cache and IMA still thinks that it is verified... BUM...

Oh. You don't actually verify the contents every time it is loaded
from disk. There's your problem.  IOWs, you won't even detect a
filesystem corruption that causes this problem if the files have
already been verified and the inodes are still in memory.

If I were an attacker, I could easily prevent detection from
occurring simply by leaving an open file sitting around. IOWs, open
all the files I wanted to modify, read them, drop the page cachend
then modify the block device directly.  And now the files full of
unverified content will now be certified as valid...

> > Seriously, if someone can modify your block device directly then
> > you've already lost and no amount of after-the-fact verification
> > will save you.
> 
> Are you talking about offline or online modification?
> Integrity protection against offline modification..
> Online is protected by Access Control...

Either. Both. It doesn't matter. Someone modifying the block device
directly means they either have already broken your access controls
or they have physical access to your machine.

> Are there any ways to detect that any of the pages have been dropped
> from the kernel page cache?

I don't think there's any reliable method for detecting that as
present.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com