Closed Bug 1497141 Opened 6 years ago Closed 6 years ago

FeaturePolicy: camera and microphone

Categories

(Core :: DOM: Security, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox64 --- fixed

People

(Reporter: baku, Assigned: baku)

References

Details

(Keywords: dev-doc-complete, Whiteboard: [domsecurity-backlog1] [domsecurity-active])

Attachments

(3 files, 2 obsolete files)

FeaturePolicy support for camera and microphone
Status: NEW → ASSIGNED
Depends on: 1497126
Whiteboard: [domsecurity-backlog1] [domsecurity-active]
Attached patch part 1 - camera (obsolete) — Splinter Review
Attachment #9015198 - Flags: review?(jib)
Attached patch part 2 - microphone (obsolete) — Splinter Review
Attachment #9015199 - Flags: review?(jib)
Attached patch part 3 - WPTsSplinter Review
Attachment #9015200 - Flags: review?(jib)
Comment on attachment 9015198 [details] [diff] [review]
part 1 - camera

Review of attachment 9015198 [details] [diff] [review]:
-----------------------------------------------------------------

I'd like to see it again over the doc check.

::: dom/media/MediaManager.cpp
@@ +2891,5 @@
> +        if (Preferences::GetBool("media.getusermedia.camera.deny", false)) {
> +          videoPerm = nsIPermissionManager::DENY_ACTION;
> +        }
> +
> +        if (videoPerm == nsIPermissionManager::UNKNOWN_ACTION) {

Nit: any reason not to prefer a simpler `} else {` here?

@@ +2894,5 @@
> +
> +        if (videoPerm == nsIPermissionManager::UNKNOWN_ACTION) {
> +          nsIDocument* doc = aWindow->GetExtantDoc();
> +          if (!doc ||
> +              !dom::FeaturePolicyUtils::IsFeatureAllowed(doc, NS_LITERAL_STRING("camera"))) {

If doc is nullptr here I think we want to err on the side of DENY_ACTION, to avoid potential timing exploits.

Or better, don't check doc at all and crash instead, since there's some precedence here for that [1]

Or if you prefer, make `doc` invariant by creating it earlier in this function and bail there if it's nullptr (or MOZ_RELEASE_ASSERT).

[1] https://searchfox.org/mozilla-central/rev/5786b9be9f887ed371c804e786081b476a403104/dom/media/MediaManager.cpp#3320

@@ +2899,5 @@
> +            videoPerm = nsIPermissionManager::DENY_ACTION;
> +          }
> +        }
> +
> +        if (videoPerm == nsIPermissionManager::UNKNOWN_ACTION) {

...then we could use `} else {` here too.

@@ +2908,3 @@
>        } else {
>          rv = permManager->TestExactPermissionFromPrincipal(
> +          principal, "screen", &videoPerm);

Ideally, we'd want feature policy to control screen sharing as well:

    dom::FeaturePolicyUtils::IsFeatureAllowed(doc, NS_LITERAL_STRING("display")

...if that's ready? https://github.com/w3c/permissions/issues/182

We can add that later too I suppose.

@@ +4141,5 @@
>      }
> +
> +    nsIDocument* doc = window->GetExtantDoc();
> +    if (!doc ||
> +        !dom::FeaturePolicyUtils::IsFeatureAllowed(doc, NS_LITERAL_STRING("camera"))) {

Same here, we should either crash, bail early (with false), or err on the side of DENY if `doc` is null.
Attachment #9015198 - Flags: review?(jib) → review-
Comment on attachment 9015199 [details] [diff] [review]
part 2 - microphone

Review of attachment 9015199 [details] [diff] [review]:
-----------------------------------------------------------------

Ah, in this patch you use the pattern I meant, but would like it in GetUserMedia() also.

::: dom/media/MediaManager.cpp
@@ +2879,5 @@
>            Preferences::GetBool("media.getusermedia.microphone.deny", false)) {
>          audioPerm = nsIPermissionManager::DENY_ACTION;
>        } else {
> +        nsIDocument* doc = aWindow->GetExtantDoc();
> +        if (!doc ||

same here.

@@ +4146,5 @@
> +
> +  auto* principal = window->GetPrincipal();
> +  if (NS_WARN_IF(!principal)) {
> +    return false;
> +  }

Like this!

@@ +4154,5 @@
>    {
> +    if (!dom::FeaturePolicyUtils::IsFeatureAllowed(doc, NS_LITERAL_STRING("microphone"))) {
> +      audio = nsIPermissionManager::DENY_ACTION;
> +    } else {
> +      rv = mgr->TestExactPermissionFromPrincipal(principal, "microphone", &audio);

Just curious, did you consider putting the feature policy check inside TestExactPermissionFromPrincipal? Maybe with doc as required arg?
Attachment #9015199 - Flags: review?(jib) → review-
Comment on attachment 9015200 [details] [diff] [review]
part 3 - WPTs

Review of attachment 9015200 [details] [diff] [review]:
-----------------------------------------------------------------

Awesome!
Attachment #9015200 - Flags: review?(jib) → review+
> ...if that's ready? https://github.com/w3c/permissions/issues/182
> 
> We can add that later too I suppose.

Right. Another one we should add is 'speaker'. Maybe I'll ping you on IRC to know what's the best way to do it. AudioChannelServie maybe?
> Just curious, did you consider putting the feature policy check inside
> TestExactPermissionFromPrincipal? Maybe with doc as required arg?

This is a very good idea! I'll think about it as a follow up.
Attached patch part 1 - cameraSplinter Review
Attachment #9015198 - Attachment is obsolete: true
Attachment #9015447 - Flags: review?(jib)
Attachment #9015199 - Attachment is obsolete: true
Attachment #9015448 - Flags: review?(jib)
Attachment #9015447 - Flags: review?(jib) → review+
Comment on attachment 9015448 [details] [diff] [review]
part 2 - microphone

Review of attachment 9015448 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/MediaManager.cpp
@@ +2887,5 @@
> +          audioPerm = nsIPermissionManager::DENY_ACTION;
> +        } else {
> +          rv = permManager->TestExactPermissionFromPrincipal(
> +            principal, "microphone", &audioPerm);
> +          NS_ENSURE_SUCCESS(rv, rv);

Looks good, just noting a behavior change here.

Before this patch, the MediaSourceEnum::Microphone test applied only to the deny pref, and we ran the "microphone" persisted permission test for all audio types.

This patch changes that behavior to skip the "microphone" persisted permission test for the behind-pref MediaSourceEnum::AudioCapture. 

This is good. If ever re-enabled, new thinking is MediaSourceEnum::AudioCapture would be covered under getDisplayMedia where audio is covered by the same permission as video. [1]

I can either open a new bug on this, or feel free to add the test for "screen" similar to how you do it in the other patch (we should rename "screen" to "display" at some point I suppose, but that might require some more thought).

[1] https://github.com/w3c/permissions/issues/182
Attachment #9015448 - Flags: review?(jib) → review+
Duplicate of this bug: 1299577
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: