[enjoytheview]

The other comment on this thread mentions that it also does something else:

>disables all the system calls not explicitly invoked by the program text of a static binary

This means that if the original library didn't have an execve call in it, you would'nt be able to use it even if with ROP. In short, this seems useful to block attackers from using syscalls that were not originally used by the program and nothing else. It can be useful.

[woodruffw]

Sure, assuming your programs don't execute other programs. I don't know much about OpenBSD specifically, but spawning all over the place is the "norm" in terms of "Unix philosophy" program design.

(I agree with the point in the adjacent thread: it's hard to know what to make of security mitigations that aren't accompanied by a threat model and attacker profile!)

[torstenvl]

*Agent Smith voice*

But what use is a fork() if you're unable to exec()?

[tedunangst]

It is now less normal for programs to run programs on openbsd.

[pdonis]

> assuming your programs don't execute other programs.

What about language runtimes? They don't execute other programs in the sense of ELF executables (although the programs they interpret might), but they have to support every syscall that's included in the language. So, for example, the Python interpreter would have to include the appropriate code for every syscall that Python byte code could call (in addition to whatever internal syscalls are used by the interpreter itself). That would be a pretty complete set of syscalls.

[woodruffw]

Yep, language runtimes are an (inevitably?) large attack surface. My understanding is that OpenBSD userspace processes can voluntarily limit their own syscall behavior with pledge[1], so a Python program (or the interpreter itself) could limit the scope of a particular process. But I have no idea how common that is.

[1]: https://man.openbsd.org/pledge

[masklinn]

A langage runtime would dispatch to the libc, which is always whitelisted.

This is only an issue for the weirdo langage runtimes who’d also refuse to use libc.

[arzig]

cough go cough

Although it is periodically useful to be able to copy a binary to some random Linux server and know it will work.

[masklinn]

Even for go it should actually work as-is: the syscalls should exist statically in the binary, so the loader can enumerate and whitelist them.

What gets blocked is the system constructing the entire thing at runtime, or at least setting the syscall number dynamically.

[saagarjha]

Isn’t that how all syscalls work? The syscall number typically goes in a register.