From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B8F4C43381 for ; Fri, 15 Mar 2019 13:51:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 722A1217F5 for ; Fri, 15 Mar 2019 13:51:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729165AbfCONvp (ORCPT ); Fri, 15 Mar 2019 09:51:45 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:37707 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727705AbfCONvp (ORCPT ); Fri, 15 Mar 2019 09:51:45 -0400 Received: from callcc.thunk.org ([66.31.38.53]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2FDpSFM032094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Mar 2019 09:51:29 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 26C51420AA8; Fri, 15 Mar 2019 09:51:28 -0400 (EDT) Date: Fri, 15 Mar 2019 09:51:28 -0400 From: "Theodore Ts'o" To: Richard Weinberger Cc: Eric Biggers , linux-mtd@lists.infradead.org, linux-fscrypt@vger.kernel.org, jaegeuk@kernel.org, linux-unionfs@vger.kernel.org, miklos@szeredi.hu, amir73il@gmail.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, paullawrence@google.com, James.Bottomley@HansenPartnership.com Subject: Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required Message-ID: <20190315135128.GL11334@mit.edu> Mail-Followup-To: Theodore Ts'o , Richard Weinberger , Eric Biggers , linux-mtd@lists.infradead.org, linux-fscrypt@vger.kernel.org, jaegeuk@kernel.org, linux-unionfs@vger.kernel.org, miklos@szeredi.hu, amir73il@gmail.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, paullawrence@google.com, James.Bottomley@HansenPartnership.com References: <1957441.Hty6t2mpXG@blindfold> <20190314230702.GE6482@mit.edu> <3651600.xvQHXhhOD0@blindfold> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3651600.xvQHXhhOD0@blindfold> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Mar 15, 2019 at 08:48:10AM +0100, Richard Weinberger wrote: > Ted, > > Am Freitag, 15. März 2019, 00:07:02 CET schrieb Theodore Ts'o: > > Richard --- stepping back for a moment, in your use case, are you > > assuming that the encryption key is always going to be present while > > the system is running? > > it is not a hard requirement, it is something what is common on embedded > systems that utilize UBIFS and fscrypt. > > Well, fscrypt was chosen as UBIFS encryption backend because per-file encryption > with derived keys makes a lot of sense. > Also the implementation was not super hard, David and I weren't keen to reinvent > dm-crypt für UBI/MTD. > > That said, I'm happy with fscrypt, it works well in production. OK, but please note that fscrypt leaks i_size and timestamp information; dm-crypt doesn't. An enterprising attacker could very easily be able to do something interesting with that information, so be sure you've thought through what the threat model for users of ubifs is going to be. If you need per-user keying, and you need to be able to mount the file system and access some of the files without having any keys, and if it's useful for an admin to be able to delete files without having the key, then fscrypt is a great fit. You are proposing changes that (optionally) eliminate that last advantage of fscrypt. So I just wanted to sanity check whether or not the other advantages are useful to you, and worth the security tradeoffs that are inherent in such a choice. If it's worth it, then great. But if it isn't, I'd much rather that you appropriately protect your users and your customers rather than be an additional user of fscrypt. :-) Cheers, - Ted