FeaturePolicy should be considered when permissions.query() is called
Categories
(Core :: DOM: Security, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox71 | --- | fixed |
People
(Reporter: baku, Assigned: tnguyen)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [domsecurity-active], [wptsync upstream])
Attachments
(1 file, 1 obsolete file)
There are many feature-policy 'features' which match 'permissions'. We should consider the feature-policy state when permissions.query() is called. For instance, if feature-policy denies 'geolocation', |permissions.query({name:'geolocation'})| should be resolved with a 'deny' PermissionStatus.
Comment 2•5 years ago
•
|
||
Sure, I can take this. I have a high-level question before I start writing a patch: it seems like our FeaturePolicy features are defined separately from our permissions. Do we have a mapping of permission -> feature? If they are identical, is the "identicality" enforced somewhere?
Depending on the answer, this patch might involve implementing that mapping. I'll do some digging but wanted to put the question here in case you can save me some archaeology :)
Updated•5 years ago
|
Reporter | ||
Comment 3•5 years ago
|
||
(In reply to Nihanth Subramanya [:nhnt11] from comment #2)
Sure, I can take this. I have a high-level question before I start writing a patch: it seems like our FeaturePolicy features are defined separately from our permissions. Do we have a mapping of permission -> feature? If they are identical, is the "identicality" enforced somewhere?
No. This is part of the issue we want to fix. I would suggest to extend this:
https://searchfox.org/mozilla-central/rev/0b7007a23bc16c857f894140e12f307bfeef2fdd/dom/security/featurepolicy/FeaturePolicyUtils.cpp#18-21
If you introduce a "const char* permissionName" (null for all the features without a associated permission), then, you can add a static function in FeaturePolicyUtils to obtain the feature-name from a permission name (and/or viceversa).
You can do this mapping in the permissionUtils.cpp too: https://searchfox.org/mozilla-central/rev/0b7007a23bc16c857f894140e12f307bfeef2fdd/dom/permission/PermissionUtils.cpp#12
But I prefer to have it in FeaturePolicyUtils.cpp. Maybe there is a better approach :)
Comment 4•5 years ago
|
||
Comment 5•5 years ago
|
||
The attachment is just a WIP for initial feedback. It adds permission names when relevant in the feature map, and exposes a function that gets the feature name for a given permission. It uses this to check FeaturePolicy when testing a permission, and if the feature is not allowed, sets DENY_ACTION. I tested this locally by forcing FeaturePolicyUtils::IsFeatureAllowed to always return false and then testing geolocation permission.
Things to consider:
- TESTS!!!!!
- Baku said we should verify that the permission API is exposed to workers.
- We should expose something (like a console error) to the frontend to indicate that the permission was auto-denied due to feature policy (probably useful for developers)
- I wonder if there's any utility in creating a new explicit permission action to indicate FeaturePolicy denial.
Comment 6•5 years ago
|
||
Nihanth, can you please make this bug block the main feature-policy one whenever you get a chance.
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
Hi Nihanth, are you still looking at this? Can I take this bug?
Comment 8•5 years ago
|
||
Yeah, feel free, I never managed to clear my head enough to resume this patch... Thanks and sorry! I unassigned myself.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 9•5 years ago
|
||
Comment 10•5 years ago
|
||
Comment 13•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•3 years ago
|
Description
•