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:	Thu, 17 Jan 2013 18:22:47 +0200
From:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	linux-kernel@...r.kernel.org, ebiederm@...ssion.com,
	zohar@...ux.vnet.ibm.com, pjones@...hat.com, hpa@...or.com,
	dhowells@...hat.com, jwboyer@...hat.com,
	linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 0/3] ELF executable signing and verification

On Tue, Jan 15, 2013 at 11:34 PM, Vivek Goyal <vgoyal@...hat.com> wrote:
> Hi,
>
> This is a very crude RFC for ELF executable signing and verification. This
> has been done along the lines of module signature verification.
>
> Why do we need it
> =================
> With arrival of secureboot, sys_kexec() is deemed dangerous. One can
> effectively bypass the secureboot feature and run its own kernel. So
> matthew garret proposed disabling sys_kexec() in secureboot mode.
>
> https://lkml.org/lkml/2012/9/4/225
>
> Later in a separate thread it was discussed how to handle the issue
> of sys_kexec() with secureboot.
>
> https://lkml.org/lkml/2012/10/24/451
>
> My takeaway from discussion was that we need to sign /sbin/kexec. Signed
> executable can get extra capability and we can allow/disallow access to
> sys_kexec() based on that capability (Thanks to Eric Biederman for the
> idea).
>
> So that's my motivation to make user space signing work so that I can
> get kdump working with secureboot enabled. There might be other people
> who might find it useful in general.
>
> What does it do
> ===============
> I have written a utility "signelf" which can take a private key and
> an x509 certificate and sign an ELF executable. This is very much done
> along the lines of module signing. There are two major differences.
> Signature are put in a section ".signature" instead of being appended
> to executable. And we calculate digest of only PT_LOAD segments and not
> the whole executable file.
>
> Upon exec(), we determine if executable is signed. If it is, then locks
> down the pages in memory (using MAP_LOCKED) and verfies the signature.
> If signature does not match, process is killed. Unsigned processes
> don't get affected at all.
>
> Currently it is expected to use these patches only for statically linked
> executables. No dynamic linking. In fact patches specifically disable
> calling interpreter. This does not prevent against somebody using dlopen()
> sutff. So don't sign binaries which do that.

How dynamic linking and interpreter are related together?

This is rather policy than enforcement.
Protection works only for statically linked binaries, because dynamic
libraries are not verified.

- Dmitry

>
> HOWTO
> =====
> Currently module signing keys are automatically loaded in module keyring
> so it is easiest to sign executable using the keys generated for module
> signing.
>
> - Compile and boot into kernel with following options enabled.
>         - CONFIG_MODULE_SIG=y
>         - CONFIG_BINFMT_ELF_SIGNATURE=y
>         - CONFIG_CRYPTO_SHA256=y
>
> - Compile "signelf" utility (Attached in a patch)
>
> - Install glibc-static
>
> - Compile a test program (say hello-world.c). Link statically with glibc
>         gcc hello-world.c -o hello-world -static
>
> - Sign hello_world using keys generated during kernel build.
>         signelf -i hello-world -o hello-world.signed -p linux-2.6/signing_key.priv -c linux-2.6/signing_key.x509
>
> - Run signed executable
>         ./hello-world.signed
>
> This should run successfully. Now one can generate another pair of keys
> and certificate and sign same binary using new keys. This new binary should
> fail to execute as corresponding keys are not loaded in kernel.
>
>         openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 -config linux-2.6/x509.genkey -outform DER -out new_signing_key.x509 -keyout new_signing_key.priv
>
>         signelf -i hello-world -o hello-world.signed.new -p new_signing_key.priv -c new_signing_key.x509
>
> - Run this signed executable
>         ./hello-world.signed.new
>         Killed
>
> TODO
> ====
> - kexec related patches are yet to be done.
> - Disable ptrace to signed processes so that one can not modify code/data
>   of signed process.
> - Sort out issues related to how key used for user space signing is loaded
>   in kernel keyring.
> - Sort out issues related to sharing keyring with modules.
>
> Thanks
> Vivek
> Vivek Goyal (3):
>   module: export couple of functions for use in process signature
>     verification
>   binfmt_elf: Verify signature of signed elf binary
>   binfmt_elf: Do not allow exec() if signed binary has intepreter
>
>  fs/Kconfig.binfmt       |    7 +
>  fs/binfmt_elf.c         |  465 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/module.h  |    8 +
>  kernel/module_signing.c |    4 +-
>  4 files changed, 482 insertions(+), 2 deletions(-)
>
> --
> 1.7.7.6
>
> --
> 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/
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ