This is the tracking bug for our GSoC WASM sandboxing project. The goal is to compile legacy libraries to WASM as an intermediary step and then compile them back to object code. We'll then provide a wrapper toolkit to safely interact with the "sandboxed" library code. Full proposal below.

Toolkit for sandboxing third-parties libraries in Firefox

Firefox supports a long tail of infrequently used image and audio formats to support the occasional website that uses them. Each such format requires the Firefox decoder to use a new open source library for parsing and decoding. This, unfortunately, increases the attack surface of Firefox and as we saw in Pwn2Own 2018, Firefox was successfully exploited via a bugs in such libraries (libogg in this case).

This project proposes to sandbox third-party libraries in Firefox by building a new software-fault isolation toolkit. Our tookit will build on the WebAssembly compiler to isolate libraries in Firefox. But, as part of this toolkit we will also develop and apply a library for safely interfacing with sandboxed libraries (and sanitizing data coming from them). with this toolkit we can ensure that any vulnerability in third-party libraries (e.g., libogg or libpng) cannot be used to be used to compromise Firefox.

Goals

In order of priority:

1. Create a proof-of-concept for at least one library that is fully integrated into the Firefox build system
2. Enabled for at least one tier-1 platform on nightly behind a flag
3. Gather performance statistics
4. Expand to further libraries and

As a general question, why is this in the JavaScript: WebAssembly component? In particular, will this touch the JavaScript engine itself (Baldr/Rabaldr/Cranelift), or is this just because this is related to WebAssembly? If the former is true, then it's fine to have all these bugs in this component; otherwise, I'd strongly suggest moving these bugs to another component, so it is easier to track the work being done as part of our wasm implementation (which is the purpose of this component), please.

(In reply to Benjamin Bouvier [:bbouvier] from comment #1)

As a general question, why is this in the JavaScript: WebAssembly component? In particular, will this touch the JavaScript engine itself (Baldr/Rabaldr/Cranelift), or is this just because this is related to WebAssembly? If the former is true, then it's fine to have all these bugs in this component; otherwise, I'd strongly suggest moving these bugs to another component, so it is easier to track the work being done as part of our wasm implementation (which is the purpose of this component), please.

It's the latter, I'll move it and file WASM specific bugs in this component if anything comes up.

Thanks Eric!

Hi there, I am Shivam a UG student from India. I have contributed for Mozilla in past and understand the development process.
I see Shravan Narayan is working on this feature addition alone with some mentors. I remember this was the project for which I applied as well and was rejected. Fast forward 6 months from the start of Gsoc I see that Gsoc 2019 has been completed but this project is yet to be completed.
Thus it now appears that community can contribute to the same. Having studied wasm, and the toolkits that would be used during the past Gsoc application I would like to help Shravan out in completing this meta task.
I am sure that mentors don't have any problem if I start working on a subtask that is not currently being worked on by Shravan.
Shravan what do you think?

Any good issue where I can start from?

(In reply to shivambalikondwar from comment #4)

Hi there, I am Shivam a UG student from India. I have contributed for Mozilla in past and understand the development process.
I see Shravan Narayan is working on this feature addition alone with some mentors. I remember this was the project for which I applied as well and was rejected. Fast forward 6 months from the start of Gsoc I see that Gsoc 2019 has been completed but this project is yet to be completed.
Thus it now appears that community can contribute to the same. Having studied wasm, and the toolkits that would be used during the past Gsoc application I would like to help Shravan out in completing this meta task.
I am sure that mentors don't have any problem if I start working on a subtask that is not currently being worked on by Shravan.
Shravan what do you think?

Hi shivambalikondwar, thanks for your interest! We are in the process of getting all of the dependencies landed so that we can start sandboxing graphite (bug 1566288). Once we get everything landed and clear out any follow-up issues we'll definitely be open to contributions. I'd suggest checking back in about a month to see where we're at.

Anything I can do in the meanwhile Eric? I mean any deps/libraries to study that will shorten the time needed to start contributing.

The following is a quick tutorial on how to use the RLBox library sandboxing framework. Working through this will help you get started. https://docs.rlbox.dev/

Great its past one month i think i can begin working.