linux-kernel - Re: [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned

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]

Date:	Fri, 25 Jan 2013 13:42:05 +0100
From:	Stephan Mueller <stephan.mueller@...ec.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	Kyle McMartin <kyle@...hat.com>, linux-kernel@...r.kernel.org,
	David Howells <dhowells@...hat.com>, jstancek@...hat.com
Subject: Re: [PATCH] MODSIGN: flag modules that use cryptoapi and only panic
 if those are unsigned

On 25.01.2013 00:36:01, +0100, Rusty Russell <rusty@...tcorp.com.au> wrote:

Hi Rusty,
> Kyle McMartin <kyle@...hat.com> writes:
>> After thinking about it a while, this seems like the best way to solve
>> the problem, although it does still kind of offend my delicate
>> sensibilities...
> 
> You're far too polite.  This patch was horrible, partial and ugly.

Well, in another email I suggested you may want to think about some
marker that the code of the module would contain, similar to the GPL
flag for the module (whose absence sets the tainted flag).
> 
> Stephan Mueller <stephan.mueller@...ec.com> wrote:
>> FIPS requires the module (in our case the static kernel binary with its
>> kernel crypto API plus all the crypto kernel modules) to be unavailable
>> if the module signature fails. That is an unconditional requirement.
> 
> "the module signature" here being the signature of any crypto module,
> I'm guessing from Kyle's awful patch.  Any crypto module, or just some?
> Presumably any module used by any crypto module, too?

Any module loading into the kernel crypto API must be caught and its
signature enforced. Thus Kyle's approach to catch the kernel crypto API
register function would be appropriate, if indeed we would catch all
crypto KOs that we want to catch -- see my remark to Kyle.

> 
> Because you can panic when a !sig_ok module registers a crypto
> algorithm.  Or you can panic when anyone registers a crypto algorithm
> after any module has failed the signature check.

I do not see the difference from a FIPS perspective. The crypto KO is
unavailable to any crypto user until it called the kernel crypto API
register function.

Thus, if a KO is loaded, its signature check failed and now lingers in
the kernel, I do not see how the main FIPS requirement is offended. Only
when the code in the KO registers with the crypto API, that is the
latest point when the kernel must stop that KO whose signature check
failed -- again from a FIPS perspective.
> 
> But it doesn't make much sense to pick on the crypto modules, since
> they're not well isolated from the rest of the kernel.

Technically, I am totally with you. That business of integrity check of
a subset of code that is loaded into the kernel realm is hard to grasp,
if you want to stop an attacker.

But that is not the focus of the FIPS test here. That test shall counter
accidental modifications (how unlikely they are). And I am fully aware
of the fact that this FIPS requirement does not make too much sense in
software implementations. Note, FIPS 140-2 mainly focuses on hardware
and has some requirements which are totally bogus for software -- this
is one of them.

Well, but if we want to be FIPS 140-2 compliant, either we meet that
requirement, or, well, you are not compliant. It is that easy. :-)

Ciao
Stephan
> 
> Thanks,
> Rusty.
> 

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