Ted, On 22.09.2016 15:44, Theodore Ts'o wrote: > On Thu, Sep 22, 2016 at 02:24:35PM +0200, Richard Weinberger wrote: >> Why do we need this check? AFAIK this situation can never happen unless due to >> a bug in the filesystem code. > > Or in the case of a malicious attacker who is trying to achieve an > off-line attack on your file system.... applications aren't going to > be checking to see if they are writing their file with encryption > enabled (and with the correct key), because they will largely be > encryption oblivious. > > So imagine a case where you have a file, say, dissidents.txt. This > file is encrypted, and is in a encrypted directory. The bad guy, in > an offline attack (e.g., using a tool like debugfs), creates a > replacement directory which is unencrypted, and creates a link to the > encrypted dissidents.txt file to that replacement directory. > > You then go back to your hotel room in Beijing, boot your laptop, fire > up your editor, and then edit the dissidents.txt file. You have the > keys, so it is read in just fine into vi or emacs. But when when you > write out the file, the editor writes the file into > dissidents.txt.new, calls fsync on it, and then renames dissidents.txt > to dissidents.txt~, and renames dissidents.txt.new to dissidents.txt. > But since it is now in an unencrypted directory, dissidents.txt is now > unencrypted. Got it. So, the use case is preventing off-line attacks. But I fear this is only a drop in the bucket. What we really need is meta data authentication. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
