From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755118AbbETQJ5 (ORCPT ); Wed, 20 May 2015 12:09:57 -0400 Received: from lan.nucleusys.com ([92.247.61.126]:42830 "EHLO zztop.nucleusys.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754095AbbETQJH (ORCPT ); Wed, 20 May 2015 12:09:07 -0400 X-Greylist: delayed 1148 seconds by postgrey-1.27 at vger.kernel.org; Wed, 20 May 2015 12:09:07 EDT Date: Wed, 20 May 2015 19:08:40 +0300 From: Petko Manolov To: "Luis R. Rodriguez" Cc: Mimi Zohar , Matthew Garrett , Rusty Russell , Casey Schaufler , Andy Lutomirski , linux-security-module , James Morris , serge@hallyn.com, "linux-kernel@vger.kernel.org" , linux-wireless , David Howells , Kyle McMartin , David Woodhouse , Seth Forshee , Greg Kroah-Hartman , Joey Lee , Konstantin Ryabitsev , Kees Cook Subject: Re: [RFD] linux-firmware key arrangement for firmware signing Message-ID: <20150520160840.GB10473@localhost> Mail-Followup-To: "Luis R. Rodriguez" , Mimi Zohar , Matthew Garrett , Rusty Russell , Casey Schaufler , Andy Lutomirski , linux-security-module , James Morris , serge@hallyn.com, "linux-kernel@vger.kernel.org" , linux-wireless , David Howells , Kyle McMartin , David Woodhouse , Seth Forshee , Greg Kroah-Hartman , Joey Lee , Konstantin Ryabitsev , Kees Cook References: <20150519200232.GM23057@wotan.suse.de> <1432072117.4510.180.camel@linux.vnet.ibm.com> <20150519221902.GQ23057@wotan.suse.de> <1432078625.4510.207.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.0 (-) X-Spam-Report: Spam detection software, running on the system "zztop.nucleusys.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 15-05-19 17:22:59, Luis R. Rodriguez wrote: > > I have a series of reasons find IMA unsuitable for the current goals at hand: > > 1) IMA is a pretty big kitchen sink, we want this to work well for > even embedded systems, or architectures that do not have or require > TPMs [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15-05-19 17:22:59, Luis R. Rodriguez wrote: > > I have a series of reasons find IMA unsuitable for the current goals at hand: > > 1) IMA is a pretty big kitchen sink, we want this to work well for > even embedded systems, or architectures that do not have or require > TPMs No, it isn't. I've profiled it and performance hit is negligible. All hash algorithms used have been optimized for most cpu architectures. > 2) The appraisal is also done for to account for a specific state of > affairs, you appraise to the user of the integrity of the system at a > specific point in time, firmware signing can provide integrity / > authorship vetting of files directly from the authors. In the case of > regulatory.bin that was the whole point of it, and firmware signing as > is being provided is intended to generalize that but by sharing code > in-kernel with module signing infrastructure This is weird English to me, but since i am no native speaker either i'll blame myself. :) Could you please rephrase? > If we go with IMA, I however do not think this would be appropriate and > overkill at this point in time. Depends on what your needs are. If you need authenticity then IMA-appraise is definitely your way to go. For anything less secure you may go with LSM of choice to apply whatever policy you may have in mind. Again, security and convenience do not play well together. Petko