From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Thompson Subject: Re: [PATCH 0/12: eCryptfs] eCryptfs version 0.1 Date: Mon, 21 Nov 2005 16:11:29 -0600 Message-ID: References: <20051119041130.GA15559@sshock.rn.byu.edu> <20051118221659.64515ac0.akpm@osdl.org> <20051121202825.GA17946@halcrow.us> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Michael Halcrow , Andrew Morton , Phillip Hellewell , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, viro@ftp.linux.org.uk, mhalcrow@us.ibm.com, mcthomps@us.ibm.com, yoder1@us.ibm.com Return-path: Received: from xproxy.gmail.com ([66.249.82.194]:9339 "EHLO xproxy.gmail.com") by vger.kernel.org with ESMTP id S1751126AbVKUWLa convert rfc822-to-8bit (ORCPT ); Mon, 21 Nov 2005 17:11:30 -0500 Received: by xproxy.gmail.com with SMTP id s14so797821wxc for ; Mon, 21 Nov 2005 14:11:30 -0800 (PST) To: James Morris In-Reply-To: Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 11/21/05, James Morris wrote: > On Mon, 21 Nov 2005, Michael Halcrow wrote: > > > I think you brought up two categories of potential security > > vulnerabilities. > > > The first has to do with the theoretical security of > > the algorithms -- do the encrypted files really have the attribute > > such that decrypting the files without the proper key is > > computationally infeasible? This is the job for the cryptographers to > > confront. > > > > The other category has to do with ``exploits''; I assume you are > > talking about -- for instance -- malicious files that are able to > > circumvent the intended behavior of the code. Such vulnerabilities may > > coerce the filesystem to dump the secret key out to an insecure > > location. This is an extension of the general ``correctness'' problem > > that can be an issue with any code. I would say that this is the job > > of the engineers to help prevent. It basically involves verification > > that eCryptfs is handling all of its memory correctly (i.e., via data > > and control flow analysis). > > There's a third important category: the design of the _system_. > > (Which you end up discussing somewhat further in the email). > > It would be great to have a document which describes the design of the > system and includes a comprehensive security analysis. Kernel programmers making documentation? You must be joking! (Side joke... someone somewhere, which I have now forgetten, made a similar comment). For documentation, nothing formal exists, and while we were planning on having some, it sounds like it might be a good thing to start sooner than later. I (or someone else) will get back to you when we figure out how we want to approach this. > > > - James > -- > James Morris > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Michael C. Thompson Software-Engineer, IBM LTC Security