From: "Kasatkin, Dmitry" Subject: Re: [RFC 1/1] ima: digital signature verification using asymmetric keys Date: Tue, 29 Jan 2013 10:53:30 +0200 Message-ID: References: <53febcf9f13e59a1ddd8f8c9826cadbe663f2295.1358246017.git.dmitry.kasatkin@intel.com> <1358895228.2408.14.camel@falcor1> <20130125210157.GA13152@redhat.com> <20130128151527.GA5868@redhat.com> <20130128185242.GB5868@redhat.com> <1359402694.3906.53.camel@falcor1> <20130128201316.GA14405@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Mimi Zohar , dhowells@redhat.com, jmorris@namei.org, linux-security-module@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org To: Vivek Goyal Return-path: In-Reply-To: <20130128201316.GA14405@redhat.com> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Mon, Jan 28, 2013 at 10:13 PM, Vivek Goyal wrote: > On Mon, Jan 28, 2013 at 02:51:34PM -0500, Mimi Zohar wrote: >> On Mon, 2013-01-28 at 13:52 -0500, Vivek Goyal wrote: >> > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote: >> > >> > [..] >> > > > Ok. I am hoping that it will be more than the kernel command line we >> > > > support. In the sense that for digital signatures one needs to parse >> > > > the signature, look at what hash algorithm has been used and then >> > > > collect the hash accordingly. It is little different then IMA requirement >> > > > of calculating one pre-determine hash for all files. >> > > >> > > Yes... It is obvious. It's coming. >> > > But in general, signer should be aware of requirements and limitation >> > > of the platform. >> > > It is not really a problem... >> > >> > Ok, I have another question. I was looking at your slide deck here. >> > >> > http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf >> > >> > Slide 12 mentions that keys are loaded into the kernel from initramfs. If >> > "root" can load any key, what are we protecting against. >> > >> > IOW, what good ima_appraise_tcb policy, which tries to appraise any root >> > owned file. A root can sign all the files using its own key and load its >> > public key in IMA keyring and then integrity check should pass on all >> > root files. >> >> > So what's the idea behind digital signature appraisal? By allowing root to >> > unconditionally load the keys in IMA keyring, it seems to circumvent the >> > appraisal mechanism. >> >> Vivek, you're asking obvious questions, without understanding that what >> you want to do is only now possible because of the work that has gone >> into upstreaming the different components of the linux-integrity >> subsystem (eg. IMA, trusted/encrypted keys, EVM, (MPI library), and now >> IMA-appraisal). In case you weren't aware, Dmitry made the necessary >> changes so that the MPI library could be upstreamed for >> EVM/IMA-appraisal digital signature support. > > Hi Mimi, > > Sure. I am just trying to understand that where are we and how can I > help improve things so that I can achieve my objectives. > > The problem I am running into is that I can't find a single good > documentation here which explains how to use things. There is no > single .txt file in Documentation/ directory which explains current > state of affiars or which explains how to use any of the IMA/EVM > functionality. > There is Wiki page available which contains lots of examples and explanations. http://sourceforge.net/p/linux-ima/wiki/Home/ This is an Open Source project. Anyone can contribute and improve it. If you find that something is unclear or missing in the wiki, you are welcome to contribute/ > So I have no way left but to read code and ask obivious questions > on mailing list to figure out what components are working, what > components are work in progress or what's the intent of components > and how they are supposed to be used. > > So are we saying that all the appraisal and digital signature stuff > is not useful till we figure a way out to lock down IMA keyring. Or > it is useful only when root can load the keyring but we are trying > to appraise only non-root files. > >> >> I'm pretty sure that keyrings can be locked, preventing additional keys >> from being added. (If it isn't currently supported, it needs to be.) >> The _evm and _ima keyrings should definitely be locked. When/how this >> is done, is yet to be defined. I'm pretty sure there are a number of >> people thinking about this, including David Howells, Dmitry Kataskin, >> David Safford and myself. >> >> As I previously said, the next steps are to integrate the >> EVM/IMA-appraisal public keys in a safe and trusted manner, without >> breaking the secure boot signature chain. > > In a private conversation David howells mentioned that IMA keyring > should allow loading only if new key is trusted by an already loaded > key. He has already posted some patches for marking a keyring trusted > and loading keys only if it is signed by a trusted key. > > We were wondring that what use case is served by allowing the root > to load keys unconditionally. By understanding the use case, atleast > one can try not to break it. Please read my previous email on how to lock down the kernel keyring. - Dmitry > > Thanks > Vivek