Open
Bug 781684
Opened 12 years ago
Updated 2 years ago
Child processes should not be allowed to read all preferences
Categories
(Core :: Preferences: Backend, defect, P3)
Core
Preferences: Backend
Tracking
()
REOPENED
blocking-basecamp | - |
People
(Reporter: bent.mozilla, Unassigned)
References
Details
(Keywords: sec-other)
We should probably have a whitelist of prefs that are acceptable for a child process to read. Right now there are some (printer name, moz sync ID, maybe others) that are exposed which should not be, and we shouldn't have to worry about constantly auditing for sensitive information stored there. (Addons are probably less careful too)
This isn't really ss since all subprocesses are trusted in all shipping code.
I agree with the whitelist solution. We currently read the entire prefdb and serialize it for content processes.
It might be good to keep this hidden for now given that it might take us longer to figure out the correct whitelist than we'll have time for before shipping B2G.
Blocks: 746280
Updated•12 years ago
|
blocking-basecamp: --- → ?
Given that we are no worse off than Firefox desktop here, I don't think this is a blocker. Definitely something we can look at if we have spare cycles, but not something I'd hold the release for.
I'm even thinking we should just open the bug...
blocking-basecamp: ? → -
Updated•12 years ago
|
Group: core-security
Updated•12 years ago
|
Priority: -- → P3
Comment 4•7 years ago
|
||
This was a B2G bug. WONTFIX.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
It still seems like this is something we should do.
Updated•7 years ago
|
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•