1492223 - Gate Camera/Mic Access in a Content Process on valid, unspoofed permission prompts

Status: NEW

(Core :: WebRTC: Audio/Video, enhancement, P3)

Description

[Tom Ritter [:tjr] (OOTO until mid-August)]

[See previous discussion at https://bugzilla.mozilla.org/show_bug.cgi?id=1490475#c2 ]

With Fission, and one origin-per-content-process, we can prevent camera and mic data from passing through a content process unless the origin corresponding to it has received permission.

We can also ensure that permission prompts do not contain a spoofed origin.


One wrinkle is Bug 1299577 where an origin in a third party iframe context on a.com - when granted permission to the device - is not granted permission when in a third party iframe context on b.com.

Another wrinkle is Bug 1483631 where an origin may be simultaneously prevented from asking for permission (in a third party iframe context) and granted permission (in a first party or a different third party iframe context.)

Both of these are 'okay' in the sense that we have not violated the web platform's security model, but could be 'better' in the sandboxing model because principals would have access to data they should not. Being capable of further segmenting iframes would be valuable in this situation.

Comment 1

[Tom Ritter [:tjr] (OOTO until mid-August)]

This seems like this is strongly related to PCameras::AllocateCaptureDevice which accepts a principal from the content process and then performs validation checks on it.  We should fix that as part of this work too.

Comment 2

[Johann Hofmann [:johannh]]

I'll mention this a few more times, but if I understand Chrome's model correctly (and that's what I'd like to do once we have FP implemented), the origin of the iframe will never have permission for anything, permissions are always delegated downwards from the top level document to its children.

Comment 3

[Johann Hofmann [:johannh]]

Meaning that the permission manager only holds the record of the top-level frame and the different web APIs need to use the internal FP API to figure out whether a frame can get access.

Comment 4

[Tom Ritter [:tjr] (OOTO until mid-August)]

Yes; I think that's orthogonal to what this bug is about; which is that we shouldn't send camera/mic data to a process that doesn't have permission to receive it.  Whether that permission was granted through the old style of iframes requesting it themselves; or the new model with Feature Policy is irrelevant.

And that if we were to double-key iframe processes, we could be more granular about sending the camera/mic data.

Comment 5

[Johann Hofmann [:johannh]]

Ah, right, I was reading "permission" in the strict "permission manager" sense. Okay, that makes sense.

Comment 6

[(no longer active)]

(In reply to Johann Hofmann [:johannh] from comment #3)
> Meaning that the permission manager only holds the record of the top-level
> frame and the different web APIs need to use the internal FP API to figure
> out whether a frame can get access.

FWIW if you decided to do this, I'd appreciate if you discussed the permission manager side of things with me.  I've been trying to improve that component in a number of ways and this has been one of my goals as well.  :-)

Comment 7

[Dan Minor [:dminor]]

Setting as P3 as it's not clear from the discussion what the timeline for doing this work is. Please feel free to bump.

Comment 8

[Chris Peterson [:cpeterson]]

This bug is not a Fission MVP blocker.