Maybe Go is not the only problem, I see SBCL compiling syscalls too. Truth is libc is for C and not all programs are written in C nowadays.
Le jeu. 28 nov. 2019 à 21:04, Theo de Raadt <dera...@openbsd.org> a écrit : > > Miod Vallat <m...@online.fr> wrote: > > > > For dynamic binaries, valid regions are ld.so's text segment, the signal > > > trampoline, and libc.so's text segment... AND the main program's text. > > > > > > Unfortunately our current go build model hasn't followed solaris/macos > > > approach yet of calling libc stubs, and uses the inappropriate "embed > > > system calls directly" method, so for now we'll need to authorize the main > > > program text as well. A comment in exec_elf.c explains this. > > > > > > If go is adapted to call library-based system call stubs on OpenBSD as > > > well, this problem will go away. There may be other environments creating > > > raw system calls. I guess we'll need to find them as time goes by, and > > > hope in time we can repair those also. > > > > Or you could use an ELF note to flag binaries allowed to issue syscalls > > from their text section: only static binaries (including ld.so) and go > > binaries would need them. > > Imagine a ld.so without the flag. The kernel starts a userland process > running > there. So ld.so must be able to issue system calls > > Imagine a static binary without the flag. It would fail. > > The kernel can alreayd identify these circumstances, and does not need a flag. > > The only special case is libc.so. We discussed adding a linker option to add > a note to libc. And then build tooling to add the flag for libc. And then > ld.so > identification of this note. But does it actually matter which way this is > done? > > I fear the option would be abused for other purposes. In the future, > why would we want programs doing system calls from other segments? Are > there any legitimate compelling reasons to avoid calling the libc stubs? > I don't believe so. Especially if those segments are in network facing > programs and/or generated on the fly. At worst a nasty JIT can generate code > to call & of libc syscall(2) stub with SYS_* symbolic names. That approach > remains simple and workable for the developer, but somewhat more difficult for > an attacker who not know the relevant locations. > -- Thomas de Grivel kmx.io
