Proposal: Make Go2 better implement the Object-capability model for security.

[jaekwon]

UPDATE

We're forking to HOG-lang. https://github.com/HogLang/hog

Original proposal and motivation

This proposal is a combination of three proposals to evolve Golang towards a more secure language that is robust against malicious dependencies.

Design principle: Implement the object-capability model

0. Read-only slices
1. Secure modules w/ the const-mutable type
2. Pointerized structs

0. Read-only slices

Slices are used everywhere in Golang, but there's no native language feature to help with safety. It's not always immediately obvious whether it's safe to pass a slice, or whether that slice needs to be copied before being passed in or returned. You need to think about the performance tradeoffs of copying or not, and often that blinds you to the concern of security/mutability.

Read the read-only slices proposal here.

It's an extension to Brad's original proposal, and it introduces any and readonly modifiers to slices.

1. Secure modules w/ the const-mutable type

With most module-level vars today, it's clear that you're not really supposed to update them. Or rather, it wouldn't be secure to allow arbitrary code to update them. For example, see the var in https://golang.org/pkg/crypto/rand/ : Reader could be replaced with something bad by malicious code, and the next user of crypto/rand.Reader wouldn't know.

See the const-mutable proposal.

2. Pointerized structs

The same problem exists for pointers as for slices. One could argue that the coder should keep fields private and just use getters and setters for permissions, but public/private (exposed/unexposed) fields are not really used today in the security context of malicious code. You expose a field because the user might need read access to it and it's convenient to expose rather than writing a getter, or, because the user is expected to write to the field in a non-malicious way.

The proposed solution is to support structs that are always passed by reference.

Read the pointerized struct proposal here.

More discussions and proposals

Several people have brought up other proposals worth mentioning here. I'll continue to compile these proposals and link to them from here.

• @randall77 brought up the issue of data-races.
• @jba proposed Go2 read-only types.
• @wora proposed pure modules aka "gocap".

UPDATE

We're forking to HOG-lang. https://github.com/HogLang/hog

[ianlancetaylor]

The first part of this proposal seems closely related to #6386.

I'm not sure I understand the second part, but it seems to just be a compiler optimization. That does not need to be a proposal at all. The proposal process is primarily for user visible changes.

[jaekwon]

I'm not sure I understand the second part, but it seems to just be a compiler optimization. That does not need to be a proposal at all. The proposal process is primarily for user visible changes.

Hmm, in some cases compiler optimizations enable the user to write visibly different code, and this is such a case. Like how tail-recursion optimization or lightweight-goroutines change user behavior.

Whether Go2 decides to adopt the Compiler optimizations for immutable struct assignment proposal or not dictates how I write my code today (for Go1) and when I decode to use pointers throughout the code. And implementing this optimization later will require me to refactor a lot of code, probably introducing bugs in the process.

[davecheney]

And implementing this optimization later will require me to refactor a lot of code, probably introducing bugs in the process.

The way to refactor with confidence is to ensure your code has good unit test coverage, not insist that the langauge implements a syntax change before you start to write.

I checked Wikipedia for what capabilities based security means and it looks like most use cases are in hardware, intel iAXP432, Burroughs B5000, etc, or an operating system concept like the capabilities mask on processes in Linux.

I can see why this would be useful, but as this proposal reads today you’re not asking for capabilities on references (I’m guessing this is how it works at a programming language level), instead your asking for much requested of features like immutability and generic types.

Given that this proposal cannot be successful unless you get all the things you ask for in the proposal, and bluntly, when you ask for more than one thing, you risk getting none of them.

My suggestion would be to abandon this proposal and instead contribute to the discussion for generic types and immutablility.

[as]

I'm not sure that I understand why the word security is used in the proposal. What is your definition of security here?

[pciet]

For the second proposal you did point out the existing solution:

The type of values you can assign to a const are more expressive, so we now have no excuse to declare module-level var variables which can be (maliciously or not) modified by anyone who imports the module.
(Of course we can declare a global function func GetMyStructP() *MyStruct { ... }) that more or less does the same thing, but nobody does that because it's easier to use var, and what's the point of doing the right thing unless there's a commitment to evolve the language toward a capabilities-based system?).

For the third proposal, there are cases where modifying the stack copy of the struct in a method makes sense, such as for changing parameters before calling another method without effects on the original struct.

If you are providing a struct and you don’t want somebody to edit the contents then the private field plus getter/setter methods is still a solution.

The empty interface case is interesting because assigning the type assertion to a variable gives you a copy and it can be passed as a reference instead of the full struct. Doesn’t emptyInterfaceVar.(pack.MyType).Field = value assign to the original memory though?

An approach may be to have a wrapper struct pointing at your base struct that has no public fields and only has a Copy() method. This way you pass just the pointer down the stack but the person using it can’t get at the original memory.

I still think that running untrusted plugins in a separate process is the right solution. Here's some discussion on how to implement communication: https://stackoverflow.com/questions/9366550/go-inter-process-communication

[pciet]

Imagine writing a web browser (implemented in Golang), but instead of Javascript for websites, you have Golang scripts. When you visit a webpage, the browser loads the Golang script, parses it, filters it, mutates it, then compiles and loads it as a plugin. When you close the tab, the plugin gets released. What's currently missing is the ability to release the plugin as in the last step.

This is a great idea. Since Javascript is being written everywhere with the addition of Node.js, why not Go everywhere? We'd need a jQuery syntax.

Cancellation is a problem the context package handles, but it requires the context to be explicitly checked during processing. Since you are able to make additions to the arbitrary Go scripts you could have the plugin IPC handler trigger a context cancellation when a cancel is sent and have context checks somehow added to the script.