linux-kernel - Re: [RFC PATCH v19 1/5] exec: Add a new AT

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]

Message-ID: <871q46bkoz.fsf@oldenburg.str.redhat.com>
Date: Sat, 06 Jul 2024 17:32:12 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: Al Viro <viro@...iv.linux.org.uk>,  Christian Brauner
 <brauner@...nel.org>,  Kees Cook <keescook@...omium.org>,  Linus Torvalds
 <torvalds@...ux-foundation.org>,  Paul Moore <paul@...l-moore.com>,
  Theodore Ts'o <tytso@....edu>,  Alejandro Colomar <alx@...nel.org>,
  Aleksa Sarai <cyphar@...har.com>,  Andrew Morton
 <akpm@...ux-foundation.org>,  Andy Lutomirski <luto@...nel.org>,  Arnd
 Bergmann <arnd@...db.de>,  Casey Schaufler <casey@...aufler-ca.com>,
  Christian Heimes <christian@...hon.org>,  Dmitry Vyukov
 <dvyukov@...gle.com>,  Eric Biggers <ebiggers@...nel.org>,  Eric Chiang
 <ericchiang@...gle.com>,  Fan Wu <wufan@...ux.microsoft.com>,  Geert
 Uytterhoeven <geert@...ux-m68k.org>,  James Morris
 <jamorris@...ux.microsoft.com>,  Jan Kara <jack@...e.cz>,  Jann Horn
 <jannh@...gle.com>,  Jeff Xu <jeffxu@...gle.com>,  Jonathan Corbet
 <corbet@....net>,  Jordan R Abrahams <ajordanr@...gle.com>,  Lakshmi
 Ramasubramanian <nramas@...ux.microsoft.com>,  Luca Boccassi
 <bluca@...ian.org>,  Luis Chamberlain <mcgrof@...nel.org>,  "Madhavan T .
 Venkataraman" <madvenka@...ux.microsoft.com>,  Matt Bobrowski
 <mattbobrowski@...gle.com>,  Matthew Garrett <mjg59@...f.ucam.org>,
  Matthew Wilcox <willy@...radead.org>,  Miklos Szeredi
 <mszeredi@...hat.com>,  Mimi Zohar <zohar@...ux.ibm.com>,  Nicolas
 Bouchinet <nicolas.bouchinet@....gouv.fr>,  Scott Shell
 <scottsh@...rosoft.com>,  Shuah Khan <shuah@...nel.org>,  Stephen Rothwell
 <sfr@...b.auug.org.au>,  Steve Dower <steve.dower@...hon.org>,  Steve
 Grubb <sgrubb@...hat.com>,  Thibaut Sautereau
 <thibaut.sautereau@....gouv.fr>,  Vincent Strubel
 <vincent.strubel@....gouv.fr>,  Xiaoming Ni <nixiaoming@...wei.com>,  Yin
 Fengwei <fengwei.yin@...el.com>,  kernel-hardening@...ts.openwall.com,
  linux-api@...r.kernel.org,  linux-fsdevel@...r.kernel.org,
  linux-integrity@...r.kernel.org,  linux-kernel@...r.kernel.org,
  linux-security-module@...r.kernel.org
Subject: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)

* Mickaël Salaün:

> On Fri, Jul 05, 2024 at 08:03:14PM +0200, Florian Weimer wrote:
>> * Mickaël Salaün:
>> 
>> > Add a new AT_CHECK flag to execveat(2) to check if a file would be
>> > allowed for execution.  The main use case is for script interpreters and
>> > dynamic linkers to check execution permission according to the kernel's
>> > security policy. Another use case is to add context to access logs e.g.,
>> > which script (instead of interpreter) accessed a file.  As any
>> > executable code, scripts could also use this check [1].
>> 
>> Some distributions no longer set executable bits on most shared objects,
>> which I assume would interfere with AT_CHECK probing for shared objects.
>
> A file without the execute permission is not considered as executable by
> the kernel.  The AT_CHECK flag doesn't change this semantic.  Please
> note that this is just a check, not a restriction.  See the next patch
> for the optional policy enforcement.
>
> Anyway, we need to define the policy, and for Linux this is done with
> the file permission bits.  So for systems willing to have a consistent
> execution policy, we need to rely on the same bits.

Yes, that makes complete sense.  I just wanted to point out the odd
interaction with the old binutils bug and the (sadly still current)
kernel bug.

>> Removing the executable bit is attractive because of a combination of
>> two bugs: a binutils wart which until recently always set the entry
>> point address in the ELF header to zero, and the kernel not checking for
>> a zero entry point (maybe in combination with an absent program
>> interpreter) and failing the execve with ELIBEXEC, instead of doing the
>> execve and then faulting at virtual address zero.  Removing the
>> executable bit is currently the only way to avoid these confusing
>> crashes, so I understand the temptation.
>
> Interesting.  Can you please point to the bug report and the fix?  I
> don't see any ELIBEXEC in the kernel.

The kernel hasn't been fixed yet.  I do think this should be fixed, so
that distributions can bring back the executable bit.

Thanks,
Florian