linux-kernel - Re: [RFD] linux-firmware key arrangement for firmware signing

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: <20150521174455.GL18164@localhost>
Date:	Thu, 21 May 2015 20:44:55 +0300
From:	Petko Manolov <petkan@...-labs.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	David Howells <dhowells@...hat.com>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>, Joey Lee <jlee@...e.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Kyle McMartin <kyle@...nel.org>,
	Sedat Dilek <sedat.dilek@...il.com>,
	LSM List <linux-security-module@...r.kernel.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Konstantin Ryabitsev <mricon@...nel.org>,
	Michal Marek <mmarek@...e.cz>,
	Seth Forshee <seth.forshee@...onical.com>,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	David Woodhouse <david.woodhouse@...el.com>,
	Linux Wireless List <linux-wireless@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	James Morris <james.l.morris@...cle.com>,
	keyrings@...ux-nfs.org, Abelardo Ricart III <aricart@...nix.com>,
	"Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 09:55:42, Andy Lutomirski wrote:
> 
> I read plenty of the code.  I said "data" not "file" for a reason.
> I'll quote some code:
> 
> int ima_appraise_measurement(int func, struct integrity_iint_cache *iint,
>                              struct file *file, const unsigned char *filename,
>                              struct evm_ima_xattr_data *xattr_value,
>                              int xattr_len, int opened)
> 
> There is no struct file in init_module.
> 
> {
>         static const char op[] = "appraise_data";
>         char *cause = "unknown";
>         struct dentry *dentry = file->f_path.dentry;
>         struct inode *inode = dentry->d_inode;
>         enum integrity_status status = INTEGRITY_UNKNOWN;
>         int rc = xattr_len, hash_start = 0;
> 
>         if (!inode->i_op->getxattr)
>                 return INTEGRITY_UNKNOWN;

Yes, not all filesystems support extended attributes, but this is not 
necessarily end of the game.  IMA code may be modified to use detached 
signatures.  In fact i was considering this option not so long ago, but dropped 
the idea as more elegant solution was presented.

> I maintain my claim that IMA is not appropriate for module signing in general.  
> It might make sense for the kind of thing that Chromium does (approving of 
> modules using finit_module based on their source instead of their payload and 
> verifying the payload indirectly using IMA or dm-verity), but that's not the 
> problem that David and Luis are trying to solve.

I guess this is all backwards.  Module signing/verification must be autonomous 
process/infrastructure.  The fact that IMA may do the same for you given a few 
conditions are met does not make it a replacement.

I do not use module signing for one particular project, because we're building 
custom kernel and initramfs.  IMA is enabled early on so an attempt to read .ko 
file results in verifying it's signature.  Yes, the filesystem does support 
xattr. :)

> Also, especially for firmware on regular distros, IMA is ridiculous. IIRC 
> there is no general support for xattrs in initramfs, and there is no reason to 
> start requiring such support just to allow firmware to live in initramfs.

For regular distro, maybe.  If one needs better overall security - not so - i 
actually quite like IMA. ;) Adding xattrs to initramfs is not bad idea at all, 
IMA arguments aside.

> I think that using IMA for this has a similar problem to using PKCS#7: it's a 
> big hammer that is much more complex than necessary to solve the problem at 
> hand.

Absolutely.  Using IMA just for module signing is a bit of an overkill.


		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/