Assuming the Go port integrates with the mitigations, then this is the combination of a memory-safe language, an ecosystem with lots of web-oriented libraries, a privilege dropping feature, and OS with few 0-days w/ history of networking deployments. That’s quite a step toward a platform for web apps highly resistant to code injection attempts. All they need now is an Airship, Opa, or Ur/Web like framework in Go that immunizes you from most web attacks by design. I mean, I don’t use Go so there might already be one I don’t know about.
I’m familiar with Ur/Web but “Airship” and “Opa” are difficult to google terms, could you link me to their web pages?
Too bad go still can’t drop privileges properly, (say, to bind to a privileged port as non root). The only work around I’ve seen is to pass the listen fd via command line wrapper written in C or myrddin.
I just use setcap, not the same as private drop but at least privs are restricted.
imo, this is not as cool as it sounds. This was added by an external contributor, the Go team likely doesn’t care nor will use it in any of the official go tools. I’m guessing that someone added it for their own project, which, while super cool for their project, isn’t the same as Golang signaling support for this mechanism.
That said, Go’s typical concurrency model does not work well with pledge. All of the concurrency primitives that are typically used to separate concerns where you’d want to drop privileges with pledge operate on goroutines, not processes. It’s definitely possible to write a privsepped + pledge daemon in Golang, but it’s not easy nor is it likely to become a common practice.
This was added by an external contributor, the Go team likely doesn’t care nor will use it in any of the official go tools.
It’s a native interface to a system call, how did you interpret that to mean that the Go team is (or isn’t) going to switch everything to OpenBSD just to be able to use pledge?
This was added by an external contributor, the Go team likely doesn’t care nor will use it in any of the official go tools. I’m guessing that someone added it for their own project, which, while super cool for their project, isn’t the same as Golang signaling support for this mechanism.
Someone created a 3rd party package that only did pledge, Brad Fitzpatrick (a core Go team member) requested that it be upstreamed and so it was submitted as a formal addition to the core unix package. It stalled out, I asked what the status was, and Brad did the work to clean it up and then commit it.
My assertion is that this change isn’t indicative of any intent for any type of wider adoption of privsep/privdrop practices by any of the golang core. I guess I don’t really understand the excitement behind this merge.
You are right. This change is not indicative of anything. In particular, it’s not in the standard library, so the Go project can’t use it. It’s in the x/sys/unix repository.
x/sys/unix is just a dumping ground for all possible system calls so that Go users can use it, if they need it. If the standard library needs it, it goes into syscall not x/sys/unix.
If you have ideas for places this would be useful in libraries, running binaries or in the standard library, I can try to submit some OpenBSD-specific patches to run pledge before making a system call.
It’s not possible to use it in the standard library because it’s not in the standard library. It’s in a second-class repository maintained by the Go project.
Of course we could add it to the standard library if we had a specific need for it, but it’s a hard sell.
Its mostly as easy as C, especially given there is a built in rpc package that works decently.
Very cool. Hope they ad the cap_* (capsicum) syscalls for FreeBSD, DragonFly, Linux and other unix-like operating systems too.
Even cooler would be CloudABI, which is more involved, but would be amazing for typical Golang use cases.