On 2020/5/5 下午4:11, Johannes Thumshirn wrote: > On 04/05/2020 22:59, Eric Biggers wrote: > [...] > >> But your proposed design doesn't do this completely, since some times of offline >> modifications are still possible. >> >> So that's why I'm asking *exactly* what security properties it will provide. > > [...] > >> Does this mean that a parent node's checksum doesn't cover the checksum of its >> child nodes, but rather only their locations? Doesn't that allow subtrees to be >> swapped around without being detected? > > I was about to say "no you can't swap the subtrees as the header also > stores the address of the block", but please give me some more time to > think about it. I don't want to give a wrong answer. My personal idea on this swap-tree attack is, the first key, generation, bytenr protection can prevent such case. The protection chain begins from superblock, and ends at the leaf tree blocks, as long as superblock is also protected by hmac hash, it should be safe. Btrfs protects parent-child relationship by: - Parent has the pointer (bytenr) of its child The main protection. If attacker wants to swap one tree block, it must change the parent tree block. The parent is either a tree block (parent node), or root item in root tree, or a super block. All protected by hmac csum. Thus attack can only do such attach by knowing the key. - Parent has the first key of its child Unlike previous one, this is just an extra check, no extra protection. And root item doesn't contain the first key. - Parent has the generation of its child tree block This means, if the attacker wants to use old tree blocks (since btrfs also do COW, at keeps tree blocks of previous transaction), it much also revert its parent tree block/root item/superblock. The chain ends at superblock, but superblock is never COWed, means attacker can't easily re-create an old superblock to do such rollback attack. Also btrfs has backup super blocks, backup still differs from the primary by its bytenr. Thus attacker still needs the key to regenerate a valid primary super block to rollback. But this still exposed a hole for attacker to utilize, the usebackuproot mount option, to do such rollback attack. So we need to do something about it. > > [...] > >> Actually, nothing in the current design prevents the whole filesystem from being >> rolled back to an earlier state. So, an attacker can actually both "change the >> structure of the filesystem" and "roll back to an earlier state". > > Can you give an example how an attacker could do a rollback of the whole > filesystem without the key? What am I missing? As explained, attacker needs the key to regenerate the primary superblock, or use the usebackuproot mount option to abuse the recovery oriented mount option. The only attack I can thing of is re-generating the csum using non-authentic algorithm, mostly in user space. But it can be easily detected. Thanks, Qu > >> It very well might not be practical to provide rollback protection, and this >> feature would still be useful without it. But I'm concerned that you're >> claiming that this feature provides rollback protection when it doesn't. > > OK. > > [...] > >> The data on disk isn't trusted. Isn't that the whole point? The filesystem >> doesn't trust it until it is MAC'ed, and to do that it needs the MAC algorithm. > > OK, will add this in the next round. > > Thanks, > Johannes >
Attachment:
signature.asc
Description: OpenPGP digital signature
