Context-Based Security

[npmccallum]

There are a number of functions which take no context as input. I think I have caught all of them:

• options_open
• secrets_manager_open
• keypair_generate
• keypair_import
• publickey_import
• secretkey_import
• signature_import
• symmetric_key_generate
• symmetric_key_import

• symmetric_state_open

  These functions do not align with the general strategy of context-based security as used in other WASI specifications. All WASI functions should have some context object (i.e. handle) which is either provided by the runtime or derived from a handle provided by the runtime.

  One suggestion for this handle might be a policy handle which allows the runtime to define which algorithms are permitted.

[jedisct1]

Shouldn't that context be added to all functions, maybe as the first parameter?

[npmccallum]

@jedisct1 No. You can chain them. For example: policy => storage_manager => keypair. In this case, the keypair handle has reference to the policy indirectly through the storage_manager.

[jedisct1]

Got it.

And if the root context is read-only, lock contention shouldn't be an issue.

How do applications get that root context? Should some kind of init() function be added?

[npmccallum]

The handle is a preopen. No init() function is needed or desired.

[jedisct1]

But how do libraries get that handle? Is it by looking for a specific path such as /dev/crypto?

[npmccallum]

@sunfishcode is working on this currently. Thoughts?

[npmccallum]

@jedisct1 Generally, I would expect them to expect the crypto policy as input.

[sunfishcode]

Yes, it sounds like this is a handle that the program should declare as an input argument, though the specific mechanisms for doing this aren't implemented yet.