Conversation

Replying to and
Thanks for sharing, awesome work! The exploit table really shows how effective the Android/Linux sandboxing model is for chrome. Other platforms seem to go renderer->kernel, but the tight seccomp policy on Linux makes that jump extremely tough.
1
5
By the way, the Layer-1 Chromium sandbox on Android is available to every other app via isolatedProcess="true" on service processes. It's massively underused. It would be nice if it gave you an easy way to set up a comparable seccomp-bpf filter too. It's tricky to do yourself.
1
5
Setting up seccomp filters is extremely tough, especially on an active code base. Requires a lot of maintenance if you want to be strict. Even if the code base is static, updating libraries/dependencies means updating the policy. Edge case violations are really hard to find.
1
1
It could use a much better filter than it currently does for a newer revision of isolatedProcess. Lack of isolatedProcess adoption probably leads to them not attempting to bring benefits of Chromium's seccomp-bpf filter to other apps. Unfortunate that few apps/libraries care.
1
It's designed in a way that's it's usable by a library, not just an application. So, for example, Signal should really be using it for WebRTC, which is obviously sandboxed in Chromium... but not Signal. Would be really widely used if more developers cared about security.