On Thu, Jan 15, 2015 at 11:09:13AM -0800, Michael Halcrow wrote: > On Thu, Jan 15, 2015 at 01:56:43PM -0500, Sasha Levin wrote: > > On 01/15/2015 01:43 PM, Michael Halcrow wrote: > > > I previously presented on ext4 encryption at the 2014 Linux Security > > > Summit: > > > > > > http://kernsec.org/wiki/index.php/Linux_Security_Summit_2014/Abstracts/Halcrow > > > > > > http://kernsec.org/files/lss2014/Halcrow_EXT4_Encryption.pdf > > > > > > Our first prototype implementation has been in Ted Ts'o's unstable git > > > branch since November 2014. My team has made significant progress in > > > the months since, developing encryption policy and file name > > > encryption capabilities. We have completed the first major phase of > > > development and are preparing a patchset to iterate on the prototype. > > > > > > I will present our approach at applying different encryption policies > > > to different segments of the file system via a policy inheritance > > > scheme. I will discuss how file-granular policies can sythesize > > > multiple keys to cryptographically protect files. For example, both > > > logon credentials and off-device keys can together preclude access. > > > This work represents efforts by Ildar Muslukhov. > > > > > > I will also present the challenges involved in file name encryption on > > > a multi-tenant system and will discuss novel solutions spearheaded by > > > Uday Savagaonkar. This approach involves treating the user domain, > > > HTree domain, and disk domains for the file names separately and > > > applying different transformations depending upon whether or not the > > > encryption keys for the file names are available. > > > > > > Finally, I will discuss what our future plans are with respect to > > > encryption with integrity, which will include leveraging ext4 > > > transactions to enforce cryptographic consistency while managing > > > additional per-block authentication data. > > > > Are there any controversial topics that require a discussion here? It really > > sounds like just a presentation about ext4 encryption. > > Yes, it's largely a presentation. I'd be very happy to see this topic > rejected on the grounds that there's too little controversy. There are patches that touch bio[1] and xattr namespace[2]. Are you going to send them for review independently? [1] https://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/commit/?h=crypto&id=2b31296fa36fa18921635f6fa5fb9898dab6c6a3 [2] https://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/commit/?h=crypto&id=7721522ac6a42379f2f4ff5c1fe5d895c634a82e The first one adds 2 pointers to struct bio for everybody. I don't know how far this could be a problem so maybe the callback + data could be stored in another struct linked from bio. Second patch adds a seemingly generic global namespace to xattrs ('encryption'). AFAIK there's no authority to assign or approve xattr namespaces and we've added "btrfs" some time ago. Let's say we'd like to implement the similar encryption support into btrfs. If the namespace would be de-facto owned by ext4, extending it could be a problem if the change is not compabile. Another problem could be with user tools if the implementations of the xattr handlers differ for the filesystems. Eg. if fs.type == 'ext4' then ... do something with encryption.whatever else if fs.type == 'btrfs' then ... the same thing has to be done in another way endif I do not have a concrete example and haven't spotted apparent problems with the existing proposal, but I also haven't done any through analysis of btrfs needs in that respect. General idea here is that with the subvolumes and snapshots it would be possible to implement encryption per subvolume, where snapshots and reflinks would work within the subtree of the particular subvolume. And this may need updates to the xattr interface or inheritance rules or I don't know what. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
