Re: Ext4 data structures integrity

["Kasatkin, Dmitry" <dmitry.kasatkin@intel.com>]

On Wed, Sep 28, 2011 at 4:56 PM, Ted Ts'o <tytso@mit.edu> wrote:
> On Wed, Sep 28, 2011 at 04:42:22PM +0300, Kasatkin, Dmitry wrote:
>> Hello,
>>
>> I have a question about Ext4 data structure integrity.
>>
>> On Ext3 file system I was able to modify offline inode block mapping
>> in such a way,
>> that 2 inodes did point to the same data blocks, so when modifying one
>> file, did affect another file..
>> FSCK detects such problems and create duplicated blocks, so that inode
>> content will not overlap...
>>
>> Does Ext4 suffers from the same problem?
>
> That's not a problem that's a feature!
>
> It's REALLY REALLY BAD to try to corrupt the file system the way you
> are doing.  If you at some point delete one of the files, then that
> block will be marked free, and will get reused for something else,
> which will then result in all sorts of data consistency problems.
>
> Worse yet, if the block gets reused as a directory block, and then you
> modify the remaining file, you could end up corrupting the file system
> itself, leading to the loss of access many, many files.
>
> Since ext4 uses the same file system consistency checker as ext3, it
> will also find this sort of file system CORRUPTION, and correct it by
> duplicating the blocks.
>
> Why in the world would you want to do such a crazy thing in the first
> place?
>
>                                                - Ted
>

Hello,

Thank you for the quick response.

I work on integrity protection subsystem IMA/EVM (linux/security/integrity).
The target is to protect against offline modifications.
Using block re-mapping I was able to implement simple attack which
allows to circumvent IMA integrity verification.
In order to prevent this kind of attack, it is necessary to run fsck every boot.

I want to know if there is a better way to prevent such attacks...


Thanks,

Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html