3 ms·

Go (golang) is a great language for web applications and has comparatively small syscall coverage making it easy to sandbox with seccomp(2). It also has most of

Go (golang) is a great language for web applications and has comparatively small syscall coverage making it easy to sandbox with seccomp(2). It also has most of the protections of a fully managed language, makes making raw syscalls easy, and can be used without libc. If you don't use cgo or SWIG (pure Go and Go assembly are fine), building statically linked pure Go binaries without libc is just a couple of commandline flags. If you don't import the net package or a few other problematic packages, no commandline flags are required.

the8472 10y ago
too bad you can't do it from within the application itself. some of the security-related system calls (e.g. unshare) expect the application to be single-threaded or at least require acute awareness of threading. go's automatic threading makes this difficult.
Someone 10y ago
Apart from the 'easy to sandbox' (also debatable, as that depends way more on the functionality of the application than on what it is written in, but let's ignore that) does that matter much? pledge isn't only, or even primarily, a defense against you accidentally making syscalls you don't want to make, but a defense against malware that, having invaded your application's process, attempts to make such syscalls pretending to be you. That's code you didn't write, making the programming language choice moot.
- loosescrews 10y ago
  Not really. An effective sandbox is restrictive. Managed languages tend to use a more limited set of system calls than non-managed languages because most libraries don't make any system calls of their own. The Go runtime and standard library use a more limited set of system calls than most alternatives, so a more limited set of sandbox filters are required. Injected instructions are more likely to invoke their own system calls, so you are more likely to catch it if you have a more restrictive set of filters.
  - Someone 10y ago
    "Managed languages tend to use a more limited set of system calls than non-managed languages because most libraries don't make any system calls of their own" I have a hard time understanding how that could be true. A library either needs to use OS functionality, or it doesn't. If it needs to, managed languages cannot avoid doing so, and if it doesn't, why would non-managed languages make them, more so since a major argument for the most popular of them, C, is performance? The only argument I can see is that managed language libraries could use (fewer) other libraries or the runtime to make such calls. Neither decreases the number of system calls made by any program.

the8472 10y ago

too bad you can't do it from within the application itself. some of the security-related system calls (e.g. unshare) expect the application to be single-threaded or at least require acute awareness of threading. go's automatic threading makes this difficult.

Someone 10y ago

Apart from the 'easy to sandbox' (also debatable, as that depends way more on the functionality of the application than on what it is written in, but let's ignore that) does that matter much? pledge isn't only, or even primarily, a defense against you accidentally making syscalls you don't want to make, but a defense against malware that, having invaded your application's process, attempts to make such syscalls pretending to be you. That's code you didn't write, making the programming language choice moot.

loosescrews 10y ago
Not really. An effective sandbox is restrictive. Managed languages tend to use a more limited set of system calls than non-managed languages because most libraries don't make any system calls of their own. The Go runtime and standard library use a more limited set of system calls than most alternatives, so a more limited set of sandbox filters are required. Injected instructions are more likely to invoke their own system calls, so you are more likely to catch it if you have a more restrictive set of filters.
- Someone 10y ago
  "Managed languages tend to use a more limited set of system calls than non-managed languages because most libraries don't make any system calls of their own" I have a hard time understanding how that could be true. A library either needs to use OS functionality, or it doesn't. If it needs to, managed languages cannot avoid doing so, and if it doesn't, why would non-managed languages make them, more so since a major argument for the most popular of them, C, is performance? The only argument I can see is that managed language libraries could use (fewer) other libraries or the runtime to make such calls. Neither decreases the number of system calls made by any program.