Closed
Bug 1199857
Opened 9 years ago
Closed 8 years ago
B2G content processes can open /dev/log/* after sandbox start
Categories
(Core :: Security: Process Sandboxing, defect)
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox43 | --- | affected |
People
(Reporter: jld, Unassigned)
References
Details
(Whiteboard: sb-)
https://android.googlesource.com/platform/system/core.git/+/c796ed97466510dd5239008554decbe72825e19c means that there are two copies of the Android logging code — one in liblog, one in libcutils — and they do not share the state they keep in order to open the Android log devices only once (the first time a message is logged).
The one in liblog appears to be what's used by most code; the one in libcutils, at least on emulator-x86-kk, isn't used until after sandbox startup. But it is used — I've observed it when libcutils itself complains about not being able to open /sys/kernel/debug/tracing/trace_marker (disallowed by policy, and apparently not needed?), and by libEGL immediately before crashing when it can't find the library it wants to dlopen (which is itself the subject of an upcoming bug). There are probably others, and they're probably important for diagnostic purposes.
So we need to allow sandboxed content processes to open /dev/log/* for write. They already have those files open for write, so there isn't much security exposure from this, but it's still a thing that isn't really necessary.
This would be “fixable” by dlopen'ing libcutils and explicitly calling its version of __android_log_write with an unnecessary message.
Updated•9 years ago
|
Whiteboard: sb+
Updated•9 years ago
|
Whiteboard: sb+ → sb-
Reporter | ||
Comment 1•8 years ago
|
||
B2G-specific sandboxing bugs are WONTFIX. (I'm reasonably sure these bugs don't have implications for other platforms, but comment if I missed something.)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•