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]

Message-ID: <87y5f5km3h.fsf@rustcorp.com.au>
Date:	Mon, 04 Feb 2013 10:04:58 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Stephan Mueller <stephan.mueller@...ec.com>
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

Stephan Mueller <stephan.mueller@...ec.com> writes:
> On 25.01.2013 00:36:01, +0100, Rusty Russell <rusty@...tcorp.com.au> wrote:
>> "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.

OK, so perhaps in fips mode we should fail the various crypto register
calls if the kernel is tainted?

> 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. :-)

Two important principles here:
1) Ugliness and craziness must be contained in the subsystem which cares.
2) Minimize effort spent on craziness.

Principle #1 means I want this in the crypto subsystem, not the module
subsystem.

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