host can choose which system calls pass to each webassembly module - sandbox

part of the talk of Lin Clark in https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/:
It also gives us sandboxing because the host can choose which wasi-core functions to pass in — so, which system calls to allow — on a program-by-program basis. This preserves security.
she says host can choose which system calls pass to each wasm module. for example read() system call passes to module A and write() system call to module B.
is it implemented in wasmtime or lucet or other runtimes? or is it just a dream without implementation in real world?

Yes it is implemented in all runtimes implementing wasi. The reason is that this feature is related to import/export mechanism of WebAssembly.

Related

Node WASI vs spawning a child process

In the NodeJS docs it states the following:
The WASI API provides an implementation of the WebAssembly System Interface specification. WASI gives sandboxed WebAssembly applications access to the underlying operating system via a collection of POSIX-like functions.
My question is:
What is the biggest benefit of using the WASI API over, say, spawing some other child process or similar methods of running non-nodejs code?
I would have to assume it's faster than spawning a child process, or using some C code with bindings due to the native-api.
Maybe I'm simply misunderstanding the entire idea behind WASI, which is plausable, given that part of what makes WASM so amazing is the ability to use a server-side, full blown programming language on the web (mostly), like all the crazy tools we've seen with Go/Rust.
Is this more so for the benefit of running WASM in node, natively, and again, if so, what are the benefits compared to running child processes?
I ended up getting my answer from a post here that was removed.
In really high-level terms, WASI is simply an (systems) interface for WASM.
I ended up finding this short 'article', if you will, super helpful too!
Just as WebAssembly is an assembly language for a conceptual machine, WebAssembly needs a system interface for a conceptual operating system, not any single operating system. This way, it can be run across all different OSs.
This is what WASI is — a system interface for the WebAssembly platform.

What are the security risks associated with WASM?

Using Deno you can execute WASM on a server. WASM is sandboxed for the user's safety. From my understanding, WASM code cannot do HTTP requests or modify the DOM.
Is safety guaranteed server side too? I'm looking to run arbitrary Python code from user input on servers using pyodide but was concerned that I have missed some important security flaw.
Using Deno you can run WebAssembly modules on a server because the Deno wasi module provides an implementation of WASI, the WebAssembly system interface. Using Deno is just one way of running wasm modules on a server. You could choose between many other implementations of WASI, like the wasi module in Node.js, wasmtime, lucet, wasmer, etc.
Code [running] outside of a browser needs a way to talk to the system — a system interface.
As for your security concerns, keep in mind that your WebAssembly code runs in a sandboxed environment. It's not your host system that executes directly the code in your wasm module. It's the wasm runtime — that implements the WASI interface — that runs it. And as far as I know the only way for your code to produce side effects (e.g. perform a HTTP call, access files) is to go through appropriate APIs defined by WASI.

Library function that implements TPM2_MakeCredential

For remote attestation using a TPM, on the server-side I need the TPM2_MakeCredential function. Note that this function is implemented in the TPM but it is a bit off because it doesn't depend on any TPM state, it's completely stateless (unlike the TPM2_ActivateCredential function - to be run on the client-side - which critically depends on TPM keys). According to the documentation, it's provided as a convenience. That's OK but the problem is the server doesn't have (nor requires) a TPM. But I still want to use the TPM2_MakeCredential function.
Unfortunately, I haven't been able to find a library implementation of this function. There's a full-blown TPM2.0 emulator provided by Microsoft that the TPM.MSR libraries can interface to. This works, but it requires starting and managing the simulator process which sets up sockets etc. which I would rather avoid. I am wondering if there's a pure C/C++/C# implementation provided as a library? I have been working with various solutions but the function is not trivial to re-implement, and it's also not trivial to extract from the simulator.
It turns out the TPM.MSR library itself exposes this functionality (implemented purely in the library itself, not relying on a TPM) via the CreateActivationCredentials() function on TpmPublic.

How do I use the Asterisk Audiohooks API?

I have an VOIP application i'd like to implement, that requires me to process the audio from a call in real time during the call.
Currently, I'm using Asterisk to handle my calls, and it looks like there's a functionality built in called Audiohooks which is designed to let me access the audiostream, and process it from the dialplay
However, I can not find any documentation whatsoever on how to actually create my own audio hook, nor any recent examples on how it should be done. Are there resources that show how I could use this?
Thanks
That api is availible when you do c/c++ modules for asterisk. No external API.
For examples you can check MixMonitor,func_volume,app_conference and other similar application already developed.
Hint: after work done, you have test for memory leaks and hi-load/concurrent load. Code must be thread-safe.

What methods can we use to interoperate programming languages?

What can we do to integrate code written in a language with code written in any other language? Which techniques are more/less known? I know that some/most languages can be compiled to Java bytecode, but what do we do about the rest ?
You mention the "compile to Java" approach, and there's also the "use a .NET language" approach, so let's look at other cases. There are a number of ways you can interoperate, and it depends on what you're trying to accomplish, it's a case by case situation. Things that come to mind are
Web Services (SOAP or REST)
A text (or other) file in the file system
Use of a database to relay state or other data
A messaging environment like MSMQ or MQSeries
TCP sockets or UDP messages
Mailslots and named pipes
It depends on the level of integration you want.
Do you need the code to share data? Use a platform-neutral data format, such as JSON, XML, Protocol Buffers, Thrift etc.
Do you need to be able to ask code written in one language to perform some task for code in the other? Use a web service or similar inter-process communication layer.
Do you need to be able to call the code within a single process? The answer at that point will entirely depend on which languages you're talking about.
Direct invocations:
Direct calls (if the compilers understand each other's call stack)
Remote Procedure Call (early 90's)
CORBA (late 90's)
Remote Method Invocation (Java, with RMI stack/library in target environment)
.Net Remoting
Less tightly integrated:
Web services/SOAP
REST
The two I see most often are SWIG and Thrift. The main difference is (IIRC) Thrift opens up a port and puts a server there to marshal the data between the different languages, whereas SWIG builds library interface files and uses those to call the specified methods.
I think there are a few possible relationships among programs in different langauges...
There's shares a runtime (e.g. C# and Visual Basic) and compiled into same application/process...
There's one invokes the other (e.g. perl script that invokes a C program)...
There's talks to each other via IPC on the box, or over the network (e.g. pipes and web services)...
Unfortunately your question is rather vague.
There are ways to use different languages in the same process usually by embedding a VM or an interpreter into the executable. If you need to communicate over process boundaries there again are several possibilities many of them have been already mentioned by other answers.
I would suggest you refine your question to get more helpful answers.
On the Web, cookies can be set to pass variables between ASP/PHP/JavaScript. On a previous project I worked on, we used this to create a PHP file for downloading PDFs without revealing their location on the file system from an ASP application.
Almost every language that pretends some kind of system's development use is capable of linking against external routines with either a standard OS interface, or a C function interface. That is what I tend to use.

Resources