1026356 - Dynamic library loading in content processes

Status: RESOLVED WONTFIX

(Core :: Security: Process Sandboxing, defect)

Description

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

One of the bigger sources of post-sandboxing file opens is library loading.  On keon, some simple manual testing (using patches containing the open()/access() broker process code from Chromium, which I'll post to bug 930258) turned up these files:

/system/lib/egl/egl.cfg
/system/lib/egl/eglsubAndroid.so
/system/lib/egl/libEGL_adreno200.so
/system/lib/egl/libGLES_android.so
/system/lib/egl/libGLESv1_CM_adreno200.so
/system/lib/egl/libGLESv2_adreno200.so
/system/lib/egl/libq3dtools_adreno200.so
/system/lib/hw/gralloc.msm7627a.so
/system/lib/libDivxDrm.so
/system/lib/libETC1.so
/system/lib/libGLESv1_CM.so
/system/lib/libOmxCore.so
/system/lib/libOpenSLES.so
/system/lib/libgenlock.so
/system/lib/libgsl.so
/system/lib/libmmosal.so
/system/lib/libmmparser.so
/system/lib/libsc-a2xx.so
/system/lib/libstagefright_soft_amrdec.so
/system/lib/libstagefrighthw.so
/system/lib/libwilhelm.so

On flame I also encountered these:

/system/lib/hw/gralloc.msm8610.so
/system/lib/libmemalloc.so
/system/lib/libqdutils.so
/vendor/lib/egl/eglsubAndroid.so
/vendor/lib/egl/libEGL_adreno.so
/vendor/lib/egl/libGLESv1_CM_adreno.so
/vendor/lib/egl/libGLESv2_adreno.so
/vendor/lib/libI420colorconvert.so
/vendor/lib/libadreno_utils.so
/vendor/lib/libgsl.so
/vendor/lib/libmm-color-convertor.so
/vendor/lib/libsc-a3xx.so

And, thanks to content-process NSS as used by WebRTC (bug 964455):

/system/b2g/libsoftokn3.so
/system/b2g/libfreebl3.so

And there might be more, even on those devices.

I'd also like to specifically point out libI420colorconvert.so on flame; it, and its dependency libmm-color-convertor.so, appeared to be being opened and closed for every single video frame in CubeVid — but it wasn't actually displaying anything, so this may be a side-effect of some other bug or missing whitelist entry.  If it's not, there may also be performance considerations (cf. the /dev/genlock issue, bug 980924).

As for dealing with this, some potential options:
* walking directory trees at runtime and adding hundreds (or thousands) of files to a whitelist, which is basically what I'm doing in my prototype
* storing all the libs in a single archive, pre-opened, and using the ElfLoader from Fennec (or something like it)
* preloading enough of them before sandbox start to make the remainder easier to handle by less drastic means

Some investigation of how Chrome and ChromeOS deal with this would be in order.

Comment 1

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

Move process sandboxing bugs to the new Bugzilla component.

(Sorry for the bugspam; filter on 3c21328c-8cfb-4819-9d88-f6e965067350.)

Comment 2

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

Sorry for the bugspam; filter on 086f2ac3-ac15-4299-889b-009181af5029.

Comment 3

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

Sorry for the bugspam; filter on 086f2ac3-ac15-4299-889b-009181af5029.

Comment 4

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

B2G is no more.  Desktop also has issues with dynamic library/plugin loading in sandboxed content processes, but the notes in this bug aren't very helpful anymore — the file broker can allow entire file trees now, which is a reasonably good way to handle the problem (given that we don't really expect to get the desktop sandbox to a state where open() is completely disallowed, like we were hoping for with B2G).