lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150520160840.GB10473@localhost>
Date:	Wed, 20 May 2015 19:08:40 +0300
From:	Petko Manolov <petkan@...-labs.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Andy Lutomirski <luto@...nel.org>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	James Morris <james.l.morris@...cle.com>, serge@...lyn.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	Kyle McMartin <kyle@...nel.org>,
	David Woodhouse <david.woodhouse@...el.com>,
	Seth Forshee <seth.forshee@...onical.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Joey Lee <jlee@...e.de>,
	Konstantin Ryabitsev <mricon@...nel.org>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ