How's it going?

[indolering]

I think RLBox is really cool and important technology! I was surprised to see that there hasn't been more use of RLBox in Firefox recently and I was hoping for an update 😁.

It looks like you are working on 2.0 and I saw a paper on some formal verification of validators? I'm guessing y'all are underfunded and busy grinding out new infrastructure and that's what is holding up new projects?

[shravanrn]

@indolering Hello, thanks for your comment! To some extent, the reason you aren't seeing too many updates on this rlbox repo is that rlbox v1 seems to be working well in production and is therefore considered reasonably stable. It does what it says on the tin.

However, the rlbox plugins to support individual backends to need updates from time to time. For example, the wasm2c plugin for rlbox is at https://github.com/PLSysSec/rlbox_wasm2c_sandbox/

We are working on an rlbox v2. Here we are trying to better support sandboxing c++ libraries, get better tainted struct support, get support for movable sandboxes etc. This is actually a very complicated feature set, has a lot of ongoing experimentation, and perhaps unexpectedly, actually requires a full rewrite of RLBox so is rather time consuming. There is also a delicate balance of what c++ standard should we target, whether the support for that version is wide enough, and does it make sense to wait for something like c++ reflection support etc. to be considered before releasing a new version. From a more pragmatic standpoint, since the rlbox maintainer team is small, we want to be careful about when we have a new production ready release --- we need to make sure we are ready to support it in full for production use cases. So I unfortunately cannot promise a release date here.

There are a number of more academic explorations ongoing such as: can we fully automate checking/synthesizing the tainted data verifiers that rlbox asks you to manually write today. I would caution that these are more experimental at the moment and are unlikely to be production ready for some time yet.

Beyond rlbox directly, a more challenging bottleneck is the performance overhead of the underlying sandboxing mechanism. So we have been working on improving the overheads of sandboxing compilers like wasm2c. See WebAssembly/wabt#2395 for example. Overheads being lower also allow sandboxing to be used more widely. We have also been collaborating on building an optimized sandboxing backend directly in llvm which has much lower overheads than wasm. See https://discourse.llvm.org/t/rfc-lightweight-fault-isolation-lfi-efficient-native-code-sandboxing-upstream-lfi-target-and-compiler-changes/88380.

As far as more adoption in Firefox: please note that I am not a Firefox maintener so all of these are simply my own opinions. Browsers, unlike most applications, are sufficiently complicated that they have a mix of mechanisms to help them draw security boundaries. In Firefox, this includes using rust impls of some libraries, separating code into multiple seccomp'd processes, or rlbox library sandboxing with wasm. What mechanism is chosen to secure a particular component ends up looking like a complicated trade-off matrix of performance, (in particular, because the wasm sandboxing approach does add overheads), estimated code quality (has this library been exploited in the past), maintenance (is it hard to keep this library up to date with the upstream releases etc), critical path dependence (libraries not on perf critical paths are easier to sandbox). The libraries currently sandboxed in Firefox is basically the outcome of analyzing the current tradeoffs. Improving overheads would probably change the assessment of what libraries are reasonable to rlbox.

[indolering]

That makes sense: C++ support tends to muck things up in high-assurance land and rewrites also tend to halt progress.

What sent me down this rabbit hole was examining the Tor Browser Bundle security slider (see also) and trying to reason about the most cost efficient way to qualify subsystems that are currently disabled.

Your cost/benefit matrix might produce different results when applied to the TBB. TBB is trying to get to the point where they don't have to fork ESR and can just be a config setting for the rapid release version. It might be a profitable strategy to start by targeting the TBB with an initial implementation with the intent to eventually upstream the work once it becomes performant enough. But you probably already thought of that!

Anyways, a big thanks to your team for working on such an important technology! I hope you can get more funding!