linux-kernel - Re: [PATCH 0/3] kexec: limit kexec

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, 03 May 2018 22:51:05 +0000
From:   Matthew Garrett <mjg59@...gle.com>
To:     ebiederm@...ssion.com
Cc:     Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        David Howells <dhowells@...hat.com>,
        linux-integrity <linux-integrity@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        kexec@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] kexec: limit kexec_load syscall

On Thu, May 3, 2018 at 2:59 PM Eric W. Biederman <ebiederm@...ssion.com>
wrote:

> Matthew Garrett <mjg59@...gle.com> writes:
> > kexec_load gives root arbitrary power to modify the running kernel
image,
> > including the ability to disable enforcement of module signatures.

> No.  It does absolutely nothing to the running kernel image.
> Combined with reboot(..., LINUX_REBOOT_CMD_KEXE, ...) it does allow
> booting something different.  It is argubably a little more efficient
> than writing to a file to direct the bootloader to boot something
> different and then calling reboot.  But it is not fundamentally
> different.

It absolutely does - https://mjg59.dreamwidth.org/28746.html gives an
example. The payload just needs to return.

> > Given
> > that it weakens other security mechanisms that are designed to prevent
root
> > from disabling them, it makes sense to allow the imposition of an
> > equivalent restriction.

> Say what.  You are saying a lot of words without any specifics.  Not a
> specific threat mode.  Not which security mecahnisms you are worried
> about weakening.  Not what classes of problems you are trying to defend
> against.

I have a kernel configured with module.sig_enforce enabled - root is unable
to load kernel modules that are unsigned, and since sig_enforce is
bool_enable_only, root is unable to flip that back. Any number of security
models may be implemented with that assumption. However, root still has
access to kexec_load(), and can therefore kexec into a dummy payload that
flips that byte back to 0 and permits loading unsigned module code.

There may well be other mechanisms that permit root to gain arbitrary
ability to modify kernel code. My argument is that we should treat those as
bugs, not use their existence as a justification for leaving open known
cases.