From: Stephan Mueller <stephan.mueller@atsec.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: David Howells <dhowells@redhat.com>,
Kyle McMartin <kyle@redhat.com>,
linux-kernel@vger.kernel.org, rusty@rustcorp.com.au,
jstancek@redhat.com
Subject: Re: [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned
Date: Fri, 25 Jan 2013 13:23:44 +0100 [thread overview]
Message-ID: <51027950.2080209@atsec.com> (raw)
In-Reply-To: <20130125032007.GA15926@srcf.ucam.org>
On 25.01.2013 04:20:07, +0100, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
Hi Matthew,
> On Fri, Jan 25, 2013 at 12:14:54AM +0000, David Howells wrote:
>
>> You can't rely on someone trying to sneak a dodgy crypto module in to set the
>> flag when they build it. The detection thus needs to be done in the kernel
>> during the module load.
>>
>> Can you search the module image for "crypto_register_" I wonder? If that's
>> there, it's a crypto module.
>
> If you're trying to protect against malice rather than accident, what's
> going to stop the module from just finding and modifying data structures
> itself? If you want to panic if you've just loaded something that might
> compromise your crypto implementations, you've got to panic on all
> unsigned module loads.
That is the issue here. We want to protect against accidental changes
and modifications. Malicious attacks will never be caught by the FIPS
requirements where a module is allowed to check itself.
If an attacker is able to load any kind of kernel module, we have lost.
Period.
Thus, from a FIPS point of view the latest patch from Kyle is also
appropriate, provided the concerns I raised there are covered.
Ciao
Stephan
prev parent reply other threads:[~2013-01-25 12:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-22 18:43 [PATCH] MODSIGN: only panic in fips mode if sig_enforce is set Kyle McMartin
2013-01-22 23:17 ` Rusty Russell
2013-01-23 11:26 ` David Howells
2013-01-23 15:18 ` Stephan Mueller
2013-01-24 14:59 ` Kyle McMartin
2013-01-25 11:28 ` Stephan Mueller
2013-01-24 19:06 ` [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned Kyle McMartin
2013-01-24 19:21 ` Kyle McMartin
2013-01-24 23:36 ` Rusty Russell
2013-01-25 5:45 ` Kyle McMartin
2013-01-25 12:42 ` Stephan Mueller
2013-02-03 23:34 ` Rusty Russell
2013-01-25 12:46 ` Stephan Mueller
2013-01-25 12:18 ` Stephan Mueller
2013-02-05 22:58 ` [RFC PATCH] fips: check whether a module registering an alg or template is signed Kyle McMartin
2013-02-06 8:02 ` Stephan Mueller
2013-02-06 16:15 ` Kyle McMartin
2013-02-06 17:45 ` Stephan Mueller
2013-02-06 18:18 ` Kyle McMartin
2013-01-25 0:14 ` [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned David Howells
2013-01-25 3:20 ` Matthew Garrett
2013-01-25 12:23 ` Stephan Mueller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51027950.2080209@atsec.com \
--to=stephan.mueller@atsec.com \
--cc=dhowells@redhat.com \
--cc=jstancek@redhat.com \
--cc=kyle@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.