On Mon, Jul 08, 2024 at 06:37:14PM +0200, Florian Weimer wrote: > * Mickaël Salaün: > > > On Sat, Jul 06, 2024 at 05:32:12PM +0200, Florian Weimer wrote: > >> * 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. > > > > Can you please point to the mailing list discussion or the bug report? > > I'm not sure if this was ever reported upstream as an RFE to fail with > ELIBEXEC. We have downstream bug report: > > Prevent executed .so files with e_entry == 0 from attempting to become > a process. > <https://bugzilla.redhat.com/show_bug.cgi?id=2004942> Thanks for the info. > > I've put together a patch which seems to work, see below. > > I don't think there's any impact on AT_CHECK with execveat because that > mode will never get to this point. Correct, that is not an issue for AT_CHECK use cases.
