1498614 - Enable android:isolatedProcess on Fennec

Reporter

Description

•

7 years ago

If android:isolatedProcess is set to true, this service will run under a special process that is isolated from the rest of the system and has no permissions of its own. The only communication with it is through the Service API (binding and starting). https://developer.android.com/guide/topics/manifest/service-element#isolated

Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧

Comment 1

•

7 years ago

This idea has come up occasionally over the past few years. If I remember correctly there are still some open questions: 1. Are we going to continue using Android's service facility, or fork/exec child processes like on desktop, or some combination of those? This feature seems to require at least one service launch somewhere. (See also bug 1470591, which probably can't work in a service-launched process.) 2. How isolated is the process in concrete terms, and is that going to cause problems? What files can it read, and does that include Gecko itself (e.g., the omnijar or equivalent)? Are there interactions with, e.g., using GPU drivers for WebGL? On devices with seccomp-bpf we might be able to use system call interception and brokering to relax the restrictions, like on desktop, but intervening at the system call level is risky when we can't do per-device pre-release testing like we did on B2G, given the presence of hardware-specific plugins/libraries.

Jim Mathies [:jimm]

Updated

•

7 years ago

Priority: -- → P2

James Willcox (:snorp) (jwillcox@mozilla.com) (he/him)

Comment 2

•

7 years ago

(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #1) > This idea has come up occasionally over the past few years. If I remember > correctly there are still some open questions: > > 1. Are we going to continue using Android's service facility, or fork/exec > child processes like on desktop, or some combination of those? This feature > seems to require at least one service launch somewhere. (See also bug > 1470591, which probably can't work in a service-launched process.) I don't foresee us moving away from services. It seems likely that Android may completely block fork/exec one day, so we would like to stay on a blessed path as much as possible. (Chrome uses services too). > > 2. How isolated is the process in concrete terms, and is that going to cause > problems? What files can it read, and does that include Gecko itself (e.g., > the omnijar or equivalent)? Are there interactions with, e.g., using GPU > drivers for WebGL? I believe the only thing it really does is drop Android permissions, but some more investigation is probably necessary. All we have from the docs is: > If set to true, this service will run under a special process that is isolated from the rest of the system and has no permissions of its own. The only communication with it is through the Service API (binding and starting). > > On devices with seccomp-bpf we might be able to use system call interception > and brokering to relax the restrictions, like on desktop, but intervening at > the system call level is risky when we can't do per-device pre-release > testing like we did on B2G, given the presence of hardware-specific > plugins/libraries. Apparently Chrome is using this with some success on Android[0], so maybe we can figure this out too? I think I would break that work out into a different bug, though. [0] https://bugs.chromium.org/p/chromium/issues/detail?id=166704

Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧

Comment 3

•

7 years ago

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #2) > (In reply to Jed Davis [:jld] (⏰UTC-6) from comment #1) > > 2. How isolated is the process in concrete terms, and is that going to cause > > problems? What files can it read, and does that include Gecko itself (e.g., > > the omnijar or equivalent)? Are there interactions with, e.g., using GPU > > drivers for WebGL? > > I believe the only thing it really does is drop Android permissions, but > some more investigation is probably necessary. My understanding is that it's more than that, and involves SELinux (and may be keyed off of special uids, although we probably don't need to care about that). I think gcp found the policy source files at one point, but I don't remember the details. > > On devices with seccomp-bpf we might be able to use system call interception > > and brokering to relax the restrictions, like on desktop, but intervening at > > the system call level is risky when we can't do per-device pre-release > > testing like we did on B2G, given the presence of hardware-specific > > plugins/libraries. > > Apparently Chrome is using this with some success on Android[0], so maybe we > can figure this out too? I think I would break that work out into a > different bug, though. > > [0] https://bugs.chromium.org/p/chromium/issues/detail?id=166704 Right, but I believe that Google has some leverage over Android device vendors if their driver blobs would break Chrome; we wouldn't have that with Firefox. This has come up before when it's been discussed as an extra layer of sandboxing, but it could also be used to relax the SELinux sandbox if we need to; in that case it could possibly use a default-allow policy, which is less risky but not without risk. But if the SELinux policy works as-is, then that doesn't matter for this bug; I was just bringing it up as an option we might have.

James Willcox (:snorp) (jwillcox@mozilla.com) (he/him)

Comment 4

•

7 years ago

Yeah, the selinux policy for isolated processes is here: http://androidxref.com/9.0.0_r3/xref/system/sepolicy/prebuilts/api/28.0/public/isolated_app.te Also relevant: http://androidxref.com/9.0.0_r3/xref/device/google/marlin/sepolicy/app.te So we probably can't access the GPU. That's bad.