linux-ext4 - Re: [PATCH v3 0/3] ext4 crypto: back up encrypted files

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151216151010.GB16918@quack.suse.cz>
Date:	Wed, 16 Dec 2015 16:10:10 +0100
From:	Jan Kara <jack@...e.cz>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	mhalcrow@...gle.com
Subject: Re: [PATCH v3 0/3] ext4 crypto: back up encrypted files

On Thu 10-12-15 10:04:36, Ted Tso wrote:
> This patches allow backing up encrypted files without having access to
> the key.  Unfortunately, the key *is* necessary to restore the files,
> because establishing a link means that we have to manipulate the both
> the encrypted directory and the encrypted file, and doing this through
> the VFS interface is non-trivial.  So we have an ioctl which extracts
> the encrypted file name, and that in combination with the encryption
> metadata for the directory should be sufficient to restore the file
> name assuming the restore is done with access to the user's master
> key.
> 
> The other tricky bit is that if the file's i_size is not a multiple of
> the AES block size, we need to be able to copy a handful of bytes
> before i_size --- and O_DIRECT reads don't allow that.  There are two

Umm, I don't quite follow. O_DIRECT reads will actually read final file
block in full even if i_size is somewhere in the middle of it. We then
report only data upto i_size as transferred but that's not really
important for you. That being said I agree that relying on this is hacky
but for direct IO it kind of makes sense and creating special shadow
inode is IMO even bigger hack...

> ways of solving this.  One would be an new DIO_FLAG that rounds i_size
> up to the file system blocksize, which we would pass when reading
> encrypted files using O_DIRECT.  This would require changes to the
> core direct I/O, and may be controversial.  It also may make it more
> difficult to back port these patches to ancient BSP kernels.
> 
> So what we're doing for now is admittedly a hack.  Since encrypted
> files are read-only without access to the key, it is safe to create a
> shadow copy of the inode structure, and round up i_size in the shadow
> structure.  We only do this when reading the last block in the file,
> so the overhead shouldn't be too bad.

I'm rather concerned about the locking implications of the shadow inode.
For example holding i_data_sem for reading in ext4_get_blocks() no longer
protects against changes of inode allocation information. Thus if e.g.
another process does mmaped write allocating more blocks, we can see
inconsistent extent tree from direct read. And that's just one example of
problems we can hit, I'm not sure there are not others.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html