If I have a golang binary and as an attacker I want to inject into its memory, or replace it on disk, what would I be trying to get the application code to let me do?
it looks like the usual thing some injectors on linux would have (ptrace, memcp, memset) are off the table.
is the elf itself at least kept read only on disk (vs the static folders)? is there ever writable disk space on the image? (would be nice for storing sqlite on the remaining disk space)
given a poorly written app, how would it end up overwriting itself inside of nanoVMs?
With a default setup yes you’d be able to write over the binary if the application would let you. However, we have the exec_protection flag that can be enabled Configuration - Ops which prevents the kernel from executing code outside the main executable and anything else clearly marked. It’s not on by default because there are a few JITs out there that wouldn’t work with it. As a defender pledge and unveil are both supported and could help prevent this as well: Applying Sandbox Security to Node.JS Unikernels with OpenBSD Pledge and Unveil .
The writeable disk space is configurable up to the end user, normally via Configuration - Ops but other volumes in the case of a database for example can be mounted.