From: Ted Ts'o <tytso@mit.edu>
To: "Kasatkin, Dmitry" <dmitry.kasatkin@intel.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: Ext4 data structures integrity
Date: Wed, 28 Sep 2011 11:45:01 -0400 [thread overview]
Message-ID: <20110928154501.GB19250@thunk.org> (raw)
In-Reply-To: <CALLzPKb8vHLnUDd=pOMc3FHM45UOYwBEsRxmnza3jj6yS+rngg@mail.gmail.com>
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....
> 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.
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.
This is not a defect in the file system. It's a defect in your
expectations.
- Ted
next prev parent reply other threads:[~2011-09-28 15:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-28 13:42 Ext4 data structures integrity Kasatkin, Dmitry
2011-09-28 13:56 ` Ted Ts'o
2011-09-28 15:19 ` Kasatkin, Dmitry
2011-09-28 15:45 ` Ted Ts'o [this message]
2011-09-29 12:24 ` Kasatkin, Dmitry
2011-09-29 12:56 ` Ted Ts'o
2011-09-29 13:32 ` Kasatkin, Dmitry
2011-09-28 17:16 ` Andreas Dilger
2011-09-29 12:31 ` Kasatkin, Dmitry
2011-09-29 13:33 ` Kasatkin, Dmitry
2011-09-29 13:55 ` Ted Ts'o
2011-10-07 11:40 ` Kasatkin, Dmitry
[not found] ` <64BEDF63-5861-47C9-AC90-F41768D09F17@mit.edu>
2011-10-07 14:20 ` Kasatkin, Dmitry
2011-10-07 15:22 ` Theodore Tso
2011-11-08 23:44 ` Mimi Zohar
2011-11-10 11:21 ` Kasatkin, Dmitry
2011-09-29 16:35 ` Andreas Dilger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110928154501.GB19250@thunk.org \
--to=tytso@mit.edu \
--cc=dmitry.kasatkin@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).