[gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing

[gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing

[Carlos Silva]

[-- Attachment #1: Type: text/plain, Size: 4173 bytes --]

Hi guys,

I normally hang out on irc on #gentoo-kernel and a bunch of other #gentoo-*
channels. I stumble across the discussion of bug 447352 [1] that was
reported by a user that was enforcing module signatures on the kernel. This
made me to this patch (I talked to Mike before doing this).

Signed kernel modules require that the kernel is compiled with
CONFIG_MODULE_SIG=y so that during compilation, the public key hash is
stored in the kernel so that it can be verified later when insmod'ing an
external module. There is no problem with in-tree modules, this are sign
correctly and loaded, the problem is with out-of-the-tree modules installed
by portage; this ones are not "signing ware".

So this patch adds a new USE flag to the linux-mod.eclass named
"module-signing". We enabled, it will check if the user has selected all
the correct config options in the kernel, and optionally, where are the
private and public parts of the key so that the module is signed and
install time. If any of this fails, the installation of the module is
aborted.

From the end user perspective, if he wants to add support for this, all he
has to do is enable CONFIG_MODULE_SIG in the kernel. If no keys are found
during the build, it will be generated one. If one wants to create a key
himself, it's also possible to use this key, he just has to name it
signing_key.priv and siging_key.x509 and put it under /usr/src/linux.
After the kernel is compiled, this keys can be moved elsewhere and the path
to them specified in make.conf under the vars KERNEL_MODSECKEY and
KERNEL_MODPUBKEY.

Patch below for review, discussion and testing.
Thanks,
Carlos Silva

[1] https://bugs.gentoo.org/show_bug.cgi?id=447352


--- linux-mod.eclass 2012-09-15 16:31:15.000000000 +0000
+++ linux-mod.eclass 2013-03-06 15:57:25.808173694 -0100
@@ -125,9 +125,10 @@
 inherit eutils linux-info multilib
 EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst src_install
src_compile pkg_postrm

-IUSE="kernel_linux"
+IUSE="module-signing kernel_linux"
 SLOT="0"
-RDEPEND="kernel_linux? ( virtual/modutils )"
+RDEPEND="kernel_linux? ( virtual/modutils )
+ module-signing? ( dev-lang/perl dev-libs/openssl ) "
 DEPEND="${RDEPEND}
  sys-apps/sed
  kernel_linux? ( virtual/linux-sources )"
@@ -208,6 +209,34 @@
  fi
 }

+
+# internal function
+#
+# FUNCTION: check_module_signing
+# DESCRIPTION:
+# Checks for KERNEL_MODSECKEY, KERNEL_MODPUBKEY and verifies the files
exists
+check_module_signing() {
+ if ! use module-signing; then
+ return 1
+ fi
+
+ # Check that the configuration is correct
+ KERNEL_MODSECKEY="${KERNEL_MODSECKEY:-${KV_DIR}/signing_key.priv}"
+ KERNEL_MODPUBKEY="${KERNEL_MODPUBKEY:-${KV_DIR}/signing_key.x509}"
+ if [ ! -z "${KERNEL_MODSECKEY}x" -a ! -e "${KERNEL_MODSECKEY}" ]; then
+ eerror "KERNEL_MODSECKEY points to a missing file:"
+ eerror "${KERNEL_MODSECKEY}"
+ die "Invalid KERNEL_MODSECKEY"
+ fi
+ if [ ! -z "${KERNEL_MODPUBKEY}x" -a ! -e "${KERNEL_MODPUBKEY}" ]; then
+ eerror "KERNEL_MODPUBKEY points to a missing file."
+ eerror "${KERNEL_MODPUBKEY}"
+ die "Invalid KERNEL_MODPUBKEY"
+ fi
+
+ return 0
+}
+
 # internal function
 #
 # FUNCTION: update_depmod
@@ -581,6 +610,10 @@
  return
  fi

+ if use module-signing; then
+ CONFIG_CHECK+="${CONFIG_CHECK} MODULE_SIG"
+ fi
+
  linux-info_pkg_setup;
  require_configured_kernel
  check_kernel_built;
@@ -663,7 +696,7 @@

  # This looks messy, but it is needed to handle multiple variables
  # being passed in the BUILD_* stuff where the variables also have
- # spaces that must be preserved. If don't do this, then the stuff
+ # spaces that must be preserved. If dont do this, then the stuff
  # inside the variables gets used as targets for Make, which then
  # fails.
  eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" \
@@ -710,6 +743,12 @@
  srcdir=${srcdir:-${S}}
  objdir=${objdir:-${srcdir}}

+ if check_module_signing; then
+ ebegin "Signing module ${modulename}"
+ ${KV_DIR}/scripts/sign-file "${KERNEL_MODSECKEY}" "${KERNEL_MODPUBKEY}"
"${objdir}/${modulename}.${KV_OBJ}"
+ eend $?
+ fi
+
  einfo "Installing ${modulename} module"
  cd "${objdir}" || die "${objdir} does not exist"
  insinto /lib/modules/${KV_FULL}/${libdir}

[-- Attachment #2: Type: text/html, Size: 8123 bytes --]

Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing

[Steev Klimaszewski]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

-----Original Message-----
From: Carlos Silva <r3pek@r3pek.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for
module signing
Date: Wed, 6 Mar 2013 18:25:38 -0100

@@ -663,7 +696,7 @@
 
  # This looks messy, but it is needed to handle multiple variables
  # being passed in the BUILD_* stuff where the variables also have
- # spaces that must be preserved. If don't do this, then the stuff
+ # spaces that must be preserved. If dont do this, then the stuff
  # inside the variables gets used as targets for Make, which then
  # fails.
  eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" \


^^ Why did you remove the ' in don't ?  Seems like it was an mistake?
The rest looks fine to me, maybe Ryao can chime in, I know he was
interested in module signing.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing

[Carlos Silva]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Wed, Mar 6, 2013 at 6:32 PM, Steev Klimaszewski <steev@gentoo.org> wrote:

>   # This looks messy, but it is needed to handle multiple variables
>   # being passed in the BUILD_* stuff where the variables also have
> - # spaces that must be preserved. If don't do this, then the stuff
> + # spaces that must be preserved. If dont do this, then the stuff
>   # inside the variables gets used as targets for Make, which then
>   # fails.
>   eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" \
>
>
> ^^ Why did you remove the ' in don't ?  Seems like it was an mistake?
> The rest looks fine to me, maybe Ryao can chime in, I know he was
> interested in module signing.
>

Yeah, mistake there. I noticed after I sent the email ;)
Removed the ' so that vim syntax wouldn't freak. Disregard that part.

[-- Attachment #2: Type: text/html, Size: 1253 bytes --]

Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing

[Peter Stuge]

Carlos Silva wrote:
> If one wants to create a key himself, it's also possible to use this
> key, he just has to name it signing_key.priv and siging_key.x509 and
> put it under /usr/src/linux.

Do you know if this is a sane default?

Where do most users of signed modules store keys so far?


//Peter

Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing

[Carlos Silva]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

On Wed, Mar 6, 2013 at 8:39 PM, Peter Stuge <peter@stuge.se> wrote:

> Carlos Silva wrote:
> > If one wants to create a key himself, it's also possible to use this
> > key, he just has to name it signing_key.priv and siging_key.x509 and
> > put it under /usr/src/linux.
>
> Do you know if this is a sane default?
>
> Where do most users of signed modules store keys so far?
>

It's where the kernel build system picks them. They only have to be there
to build the kernel, nothing else. After the kernel is built, and the
modules compiled and signed against that keys, they can even be removed
from the system.

[-- Attachment #2: Type: text/html, Size: 993 bytes --]

Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing

[Peter Stuge]

Carlos Silva wrote:
> > > If one wants to create a key himself, it's also possible to use this
> > > key, he just has to name it signing_key.priv and siging_key.x509 and
> > > put it under /usr/src/linux.
> >
> > Do you know if this is a sane default?
> >
> > Where do most users of signed modules store keys so far?
> 
> It's where the kernel build system picks them.

Are you sure? I find that hard to believe? Even if I tell an external
module to build against a source tree in ~/linux/ the Makefiles will
go to look for the keys in /usr/src/linux/ ?


> They only have to be there to build the kernel, nothing else.

I'm not talking about end users, by users I mean those who use the
key files to build kernels and modules.


//Peter

Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing

[Carlos Silva]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Wed, Mar 6, 2013 at 9:14 PM, Peter Stuge <peter@stuge.se> wrote:

> Carlos Silva wrote:
> > > > If one wants to create a key himself, it's also possible to use this
> > > > key, he just has to name it signing_key.priv and siging_key.x509 and
> > > > put it under /usr/src/linux.
> > >
> > > Do you know if this is a sane default?
> > >
> > > Where do most users of signed modules store keys so far?
> >
> > It's where the kernel build system picks them.
>
> Are you sure? I find that hard to believe? Even if I tell an external
> module to build against a source tree in ~/linux/ the Makefiles will
> go to look for the keys in /usr/src/linux/ ?
>

OK, my bad here. The kernel build system looks for them on the root of the
kernel source.
To build modules, they can be anywhere as long as you have the correct path
set on make.conf:
KERNEL_MODSECKEY="/path/to/privkey"
KERNEL_MODPUBKEY="/path/to/pubkey"

This only works for modules.


> They only have to be there to build the kernel, nothing else.
>
> I'm not talking about end users, by users I mean those who use the
> key files to build kernels and modules.
>

See above. I even read online that a best practice would be to generate a
new set of keys on every kernel build actually deleting the keys after the
kernel and external modules are compiled.

[-- Attachment #2: Type: text/html, Size: 2222 bytes --]

[gentoo-dev] Re: [RFC] patch linux-mod.eclass to add support for module signing

[Steven J. Long]

On Wed, Mar 06, 2013 at 06:25:38PM -0100, Carlos Silva wrote:
> + if ! use module-signing; then
> + return 1
> + fi

use module-signing || return 1

> +
> + # Check that the configuration is correct
> + KERNEL_MODSECKEY="${KERNEL_MODSECKEY:-${KV_DIR}/signing_key.priv}"

No shell field-splits (aka word-split) assignments. If sh did that, then
things like foo=$(cmd ...) would not work; so there's no need to quote
there. It's only needed for foo="$bar baz" and the like, and foo="$*" iff
you're playing with IFS (for completeness.)

That, and case $foo in .. are the *only* two places I know of where sh
doesn't field split; bash also has [[ as below. arr[i]=$bar works, but
arr+=("$bar") requires the quotes.

> + if [ ! -z "${KERNEL_MODSECKEY}x" -a ! -e "${KERNEL_MODSECKEY}" ]; then

What is the x for there? It's forcing the first test to true and is thus
redundant. Also, bash has [[ which doesn't field-split, and is quicker:

if [[ -n $KERNEL_MODSECKEY -a ! -e $KERNEL_MODSECKEY ]]; then

Though from the above, the -n (or ! -z) test is not needed, as it's set to
$KV_DIR/signing_key.priv if empty:

if [[ ! -e $KERNEL_MODSECKEY ]]; then

I think I'd use -s instead of -e here, as an empty file is also incorrect.
(help test)

> + eerror "KERNEL_MODSECKEY points to a missing file:"
> + eerror "${KERNEL_MODSECKEY}"
> + die "Invalid KERNEL_MODSECKEY"
> + fi
> + if [ ! -z "${KERNEL_MODPUBKEY}x" -a ! -e "${KERNEL_MODPUBKEY}" ]; then

Ditto.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)