Closed Bug 776652 Opened 14 years ago Closed 13 years ago

Tracking: Apply appropriate security checks for sensitive IPDL protocols

Categories

(Core :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: cjones, Unassigned)

References

Details

Attachments

(2 files)

Some protocols, like the ones used for gfx, don't need security checks (to a first approximation). But the ones used for, e.g. telephony and SMS, do. We need to do a second pass over our protocol code and apply capability checks where required. We can go in order of most-sensitive to least-sensitive. This is the debt we've been building up while we didn't have the permission model implemented. The fact that some cross-process impls are in JS complicates this somewhat.
We should implement one or two of these fully "manually" to get a feel for what this code should look like. After that, we should consider tagging IPDL protocols/messages themselves with the required permission bits, and then auto-generating the boilerplate needed to delegate those security checks.
This isn't a complete set, but let's start here.
No longer depends on: 776672
Depends on: 776174
No longer depends on: 707626
So how does one know whether certain process has been granted permission for foo?
See bug 776649. We'll reuse that mechanism for mm too.
Attached file comments about ipdls —
I went through the ipdl files I found and tried to figure out what all needs some kind of permission check or perhaps parameter validation. Next: messageManager communication
Hmm, I missed BrowserElementParent.js and it is actually tricky one. In a way all the messages from child process would need some kind of permissions check, but in practice... maybe not. So, I assume the developers of the relevant features add needed permission checks. (hopefully it is possible to do permission checks both in JS and C++.)
Depends on: 782542
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: