On Wed, Sep 28, 2011 at 6:45 PM, Ted Ts'o <tytso@xxxxxxx> wrote: > On Wed, Sep 28, 2011 at 06:19:12PM +0300, Kasatkin, Dmitry wrote: >> >> 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... >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
