linux-kernel - Re: [PATCH] MODSIGN: only panic in fips mode if sig

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 12:28:05 +0100
From:	Stephan Mueller <stephan.mueller@...ec.com>
To:	Kyle McMartin <kmcmarti@...hat.com>
CC:	David Howells <dhowells@...hat.com>, linux-kernel@...r.kernel.org,
	rusty@...tcorp.com.au, jstancek@...hat.com
Subject: Re: [PATCH] MODSIGN: only panic in fips mode if sig_enforce is set

On 24.01.2013 15:59:07, +0100, Kyle McMartin <kmcmarti@...hat.com> wrote:

Hi Kyle,
> On Wed, Jan 23, 2013 at 04:18:32PM +0100, Stephan Mueller wrote:
>> 3. in the cipher initialization code of the crypto API (i.e. the one
>> behind crypto_register_alg()), you check the signature check flag --
>> panic the kernel when the flag shows that the signature check failed
>>
>> This way you limit the panic on signature checks in FIPS mode to the
>> crypto modules.
>>
> 
> I was hoping we could just do what we do for driver/staging and set a
> flag in modpost for crypto modules, but it looks like since we have
> crypto modules outside of crypto/ for things like aesni, that won't
> work. Maybe that is a better choice, but it seems like an awful kludge.

There is a completely different possibility though:

The reason for the panic is the requirement that if one of the integrity
tests for the crypto components fail in FIPS mode, the crypto module
(i.e. the entire kernel crypto API) must be unavailable.

Thus, another possibility is to add a global flag that indicates whether
such a test failed.

That flag is evaluated by *every* kernel crypto API interface function
and this function rejects to do anything when that flag is set.

This way, we can get rid of the panic.

But then, we still have the problem of loading unsigned kernel modules
in FIPS mode that are not related to crypto: those would still trigger
setting that global flag if the module loader is unable to identify a
crypto module.

Hence, you idea with a flag may be the way to go: add such a crypto flag
similar to the MODULE_LICENSE("GPL") for modules. Now, the module loader
should only panic or set such a global flag for modules that are marked
with something like MODULE_TYPE("CRYPTO").

Now, all modules in crypto/ and arch/*/crypto/* (or whereever) would
have such a flag added.
> 
> --Kyle
> 
Ciao
Stephan
--
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/