On Wed, Sep 28, 2011 at 6:45 PM, Ted Ts'o [off-list ref] wrote:

On Wed, Sep 28, 2011 at 06:19:12PM +0300, Kasatkin, Dmitry wrote:

quoted

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.

OK, well, the way you worded your "bug report" it sounded like you
were complaining that fsck was fixing such file system corruptions.  I
wish you would have stated explicitly what you were trying to do from
the beginning.  Grumble....

Hello..

Sorry for such impression... I did not complain...

quoted

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

I suspect your real problem is that IMA is caching the results of its
integrity check.  If you don't want to require a full fsck to catch
this kind of double-mapped blocks, then you're going to have to do the
checksum each and every time the blocks are read into memory.  This
will catch the situation where a block is double mapped.

This is exactly the problem...
After verification of the file, IMA sets status to INTEGRITY_OK.
If then I modify the content via "shadow file", then when reloading first one,
IMA will not verify it again...

The file system isn't magic, you know.  There's a reason why we don't
check for cross-linked blocks except at fsck time; because otherwise
it would be an intolerable performance penalty.  If IMA wishes to
provide this kind of guarantee, it's IMA's responsibility to inflict
this performance penalty on the user, either by forcing an fsck check
every single time, or by doing integrity checksums every time.

Yes. I know it's not magic :)
This exactly the current "already existing" solution - run fsck every boot...

This is not a defect in the file system.  It's a defect in your
expectations.

No. No. Never said like that :)

                                               - Ted

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