Conversation

Replying to

Shipping native code and asking us to trust it rather than sandboxing it is just no.

Apr 16, 2019

Replying to

It is sandboxed. It runs inside the Chrome renderer sandbox, with even more distrust than the the usual ones since it doesn't count as part of the browser. NaCl / PNaCl / WebAssembly are another layer of security inside the renderer sandbox, rather than full native code exec.

Replying to

and

The whole point of NaCl was that they came up with a scheme for running native code without arbitrary uncontained code execution. It was still run with the OS sandbox, but the point was not just giving the untrusted code full native code execution inside of that OS sandbox.

Replying to

and

PNaCl changed it by making it portable, and WebAssembly is effectively the same thing but from scratch with complete portability / avoidance of undefined behavior as a core part of it rather than based on a frozen LLVM IR subset like PNaCl with an attempt to purge those things.

Replying to

and

ARC is dead though. They gave up on using the strong renderer sandbox + NaCl within that, because they would have had to reimplement the entirety of the Android system APIs in Chrome. They made really good progress but at some point they just decided to take a shortcut instead.

Replying to

and

It's a whole lot harder to achieve 100% compatibility when you actually have to reimplement the APIs for a strong sandbox vs. just running the *entirety* of Android natively on top of a kernel with Android IPC support and separating it with namespaces and some bridging to host.

Replying to

and

Also, it didn't have any direct Linux kernel access, since it was not just in the OS sandbox directly. Apps had to target it as a separate arch (i.e. compile their native code for it). Now, they could use gVisor for the Linux kernel ABI without providing direct kernel access.

Replying to

and

There were a decent number of apps targeting it, including apps like VLC which is the kind of app that would be most difficult to support it. Apps without native code could trivially run on it. Apps with native code had to build for it and cope with having a subset of Linux APIs.

Replying to

and

I think it's unfortunate that they gave up, instead of extending with Linux kernel ABI compatibility and finishing up the Android API implementation via the Chromium broker process. It was a much stronger way to sandbox apps. It could have even been dropped into Android itself.

Replying to

and

One of my early plans for my work was to drop in ARC to Android and use it to provide a stronger app sandbox for apps compatible with it, which could have been most apps and eventually every single app if they had kept at it for a few more years with a properly resourced team...

Replying to

and

i.e. eventually fully replacing the Android application layer for all non-base-system apps with the ARC implementation using the Chromium broker process + Chromium renderer sandbox, without the web parts of Chromium (Blink, v8, etc.) which weren't part of how it was implemented.

4:14 AM · Apr 16, 2019Twitter Web Client

Replying to

and

It made apps as untrusted and as sandboxed as a web page. It has definitely bitrotted way too much by now for it to be any use, but the model it used is exactly what I want to do: take gVisor and run apps inside that, and implement a broker outside it providing the Android APIs.

Replying to

and

So the client side part is simply the existing AOSP code that runs inside the app, but the server side is a reimplementation rather than it talking to system_server, etc. directly. It can proxy to the actual AOSP system_server, it just enforces better security policy / isolation.

Show replies