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)

defect

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
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: ? → -
Group: core-security
Priority: -- → P3
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.