lkml.org 
[lkml]   [2013]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned
Date
Stephan Mueller <stephan.mueller@atsec.com> writes:
> On 25.01.2013 00:36:01, +0100, Rusty Russell <rusty@rustcorp.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.


\
 
 \ /
  Last update: 2013-02-04 04:02    [W:0.094 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site