On Thu, Sep 27, 2012 at 5:12 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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. You see it bellow... > >> 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. > Like that. > 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... > That is online attack. You need to be a root to modify block device directly... But if you already became a root - game over. Online protection is done by access control.. IMA protects against offline modification.. >> > 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. > It is different... You might have physical access to your machine storage but no root access. You could remove storage and plug it to another machine, modify data. For example you could add user to /etc/sudoers or change root password. But when when you plug it back to your machine, IMA verification fails, and you will not be able to become a root. >> 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. May be inode->i_mapping->nrpages counter might indicate that. mm/filemap.c does ++ or -- Thanks for discussion.. - Dmitry > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx -- 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
