linux-kernel - Re: [RFC PATCH] fs/compat_binfmt_elf: Introduce sysctl to disable compat ELF loader

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, 16 Sep 2021 16:46:15 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Will Deacon <will@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andy Lutomirski <luto@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Catalin Marinas <catalin.marinas@....com>,
        Kees Cook <keescook@...omium.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH] fs/compat_binfmt_elf: Introduce sysctl to disable
 compat ELF loader

On Thu, Sep 16, 2021 at 3:18 PM Will Deacon <will@...nel.org> wrote:
>
> Distributions such as Android which support a mixture of 32-bit (compat)
> and 64-bit (native) tasks necessarily ship with the compat ELF loader
> enabled in their kernels. However, as time goes by, an ever-increasing
> proportion of userspace consists of native applications and in some cases
> 32-bit capabilities are starting to be removed from the CPUs altogether.
>
> Inevitably, this means that the compat code becomes somewhat of a
> maintenance burden, receiving less testing coverage and exposing an
> additional kernel attack surface to userspace during the lengthy
> transitional period where some shipping devices require support for
> 32-bit binaries.
>
> Introduce a new sysctl 'fs.compat-binfmt-elf-enable' to allow the compat
> ELF loader to be disabled dynamically on devices where it is not required.
> On arm64, this is sufficient to prevent userspace from executing 32-bit
> code at all.
>
> Cc: Al Viro <viro@...iv.linux.org.uk>
> Cc: Andy Lutomirski <luto@...nel.org>
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Signed-off-by: Will Deacon <will@...nel.org>
> ---
>  fs/compat_binfmt_elf.c | 24 +++++++++++++++++++++++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
>
> I started off hacking this into the arch code, but then I realised it was
> just as easy doing it in the core for everybody to enjoy. Unfortunately,
> after talking to Peter, it sounds like it doesn't really help on x86
> where userspace can switch to 32-bit without involving the kernel at all.
>
> Thoughts?

I'm not sure I understand the logic behind the sysctl. Are you worried
about exposing attack surface on devices that don't support 32-bit
instructions at all but might be tricked into loading a 32-bit binary that
exploits a bug in the elf loader, or do you want to remove compat support
on some but not all devices running the same kernel?

In the first case, having the kernel make the decision based on CPU
feature flags would be easier. In the second case, I would expect this
to be a per-process setting similar to prctl, capability or seccomp.
This would make it possible to do it for separately per container
and avoid ambiguity about what happens to already-running 32-bit
tasks.

        Arnd