lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 22 Sep 2016 16:21:30 +0200 From: Richard Weinberger <richard@....at> To: Theodore Ts'o <tytso@....edu>, Jaegeuk Kim <jaegeuk@...nel.org> Cc: linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, linux-fsdevel <linux-fsdevel@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, David Gstir <david@...ma-star.at> Subject: Re: ext4, f2fs: fscrypt_has_permitted_context() check in file open 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
Powered by blists - more mailing lists