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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrU3biPZEY4hxPfUavNUP1EmBeT2H2tSfiCXw+NJmxoYqg@mail.gmail.com>
Date:	Thu, 21 May 2015 09:55:42 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Andy Lutomirski <luto@...capital.net>,
	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 Thu, May 21, 2015 at 9:51 AM, Petko Manolov <petkan@...-labs.com> wrote:
> On 15-05-21 09:39:50, Andy Lutomirski wrote:
>>
>> It's also a performance cost because the average user of this signature stuff
>> doesn't actually want IMA, and IMA is checking the wrong think anyway.
>> IMA/EVM tells us "this file validly belongs in /lib/modules/whatever according
>> to whomever we trust for the filesystem".  We want to check "is this data,
>> regardless of where it was read from, a trusted module".
>
> IMA-appraise does not care where the file comes from (although it may be
> persuaded to) and verifies file's data and meta-data against a signature.  I
> guess you should actually read the code. :)
>

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;

Even for finit_module, which does have a struct file, there is
absolutely no reason to require that the file's inode has a getxattr
operation.

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.

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.

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.

--Andy
--
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/