Ext4 encryption

Posted Apr 9, 2015 15:41 UTC (Thu) by fandingo (guest, #67019)
In reply to: Ext4 encryption by jem
Parent article: Ext4 encryption

> If the encryption is per-directory-tree I wonder how the design takes into account links to files that appear on both sides of the directory boundary.

In the case of symlinks, there's two encryption policies. The symlink itself has its contents (the link destination URI) encrypted, and the destination is also encrypted. If a user only has crypto access to the link source, she gets back an encrypted hash when accessing the destination.

The penultimate page in the design doc (https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_...) covers how symlinks are handled.

> What happens when a file is moved into or out of the encrypted directory?

It is rewritten according to the crypto policy on the destination.

> Are we gradually getting rid of this model?

No. File names and data are still separate. They're encrypted separately, even using different AES modes to provide the best crypto performance while maintaining high security for data length (CBC is faster but has some weaknesses when a single key is used for massive amounts of data, which isn't a concern with file names).

I don't see any departure from how file system structures have worked in the past.

Ext4 encryption

Posted Apr 9, 2015 16:09 UTC (Thu) by viro (subscriber, #7872) [Link]

man 2 link
man 2 rename
then reread what you'd been replying to. Note, BTW, that renaming an opened file is perfectly legal and should not disrupt an ongoing IO...

Ext4 encryption

Posted Apr 9, 2015 16:31 UTC (Thu) by jem (subscriber, #24231) [Link] (2 responses)

> In the case of symlinks, there's two encryption policies. The symlink
> itself has its contents (the link destination URI) encrypted, and the
> destination is also encrypted. If a user only has crypto access to the
> link source, she gets back an encrypted hash when accessing the
> destination.

Sigh. I should have pointed out that I meant hard links. Symlinks are not interesting.

>> What happens when a file is moved into or out of the encrypted directory?

> It is rewritten according to the crypto policy on the destination.

Ok, so what happens if I make a link to an encrypted file so that there exists a (hard) link to it both inside the encrypted directory and outside of it? Or if I make a (hard) link to a non-encrypted file that appears below the encrypted directory?

> I don't see any departure from how file system structures have worked in the past.

Well, in the "good old days" files in a file system were not arranged hierarchically, but existed as a flat collection where each file was referenced by inode number. On top of that we had directories mapping names to inodes. In the really good old days a directory was not much more than a file containing records each containing an inode number and a string giving the name of the file.

The same file could have several names in the same directory or any other directories within the same file system. The file object itself had no knowledge of under which name and from which directories it was referenced from. In fact, a file might not have a name at all but still exist. As long as the file is open for a process, you can delete it from all directories and still read or write to it.

Ext4 encryption

Posted Apr 16, 2015 0:25 UTC (Thu) by Wol (subscriber, #4433) [Link]

> The same file could have several names in the same directory or any other directories within the same file system.

I still make extensive use of this ...

Photos on my system are generally owned by root, and in an archive directory. Then they are hard-linked into various user directories. Given that they are typically 10, 16 or 24 MP in size, that saves a LOT of space when you are storing several copies of each photo ...

(not that I particularly wish to crypto-protect my photos, but other people might have similar setups to mine where they do want protection.)

Cheers,
Wol

Ext4 encryption

Posted May 20, 2018 12:00 UTC (Sun) by e4crypt (guest, #124524) [Link]

Ok, so what happens if I make a link to an encrypted file so that there exists a (hard) link to it both inside the encrypted directory and outside of it?

The name of the link outside the protected directory will obviously remain unencrypted. The contents, however, will remain inaccessible until a correct key is in the keyring.

# truncate -s 2G storage
# mkfs.ext4 storage
# tune2fs -O encrypt storage
# mkdir mountpoint
# mount storage mountpoint
# cd mountpoint
# mkdir protected plain-text
# e4crypt add_key protected
# cd protected
# wget https://static.lwn.net/images/logo/barepenguin-70.png
# ln barepenguin-70.png ../plain-text
# file ../plain-text/barepenguin-70.png 
> ../plain-text/barepenguin-70.png: PNG image data, 70 x 81, 8-bit/color RGBA, non-interlaced
# cd ../..
# umount mountpoint
# e4crypt new_session
# mount storage mountpoint
# cd mountpoint
# file plain-text/barepenguin-70.png 
> plain-text/barepenguin-70.png: writable, regular file, no read permission
# cat plain-text/barepenguin-70.png 
> plain-text/barepenguin-70.png: Required key not available

Or if I make a (hard) link to a non-encrypted file that appears below the encrypted directory?

The system won't let you.

# touch plain-text/fuck_systemd
# ln plain-text/fuck_systemd protected
> ln: failed to create hard link 'protected/fuck_systemd' => 'plain-text/fuck_systemd': Operation not permitted

May 2018. Tested with kernel 4.14.40 and e2fsprogs 1.44.1.