Closed Bug 755551 Opened 8 years ago Closed 7 years ago

Allow whitelist configuration for what plugins can and cannot be ran within a gecko-based application

Categories

(Core :: Plug-ins, defect)

15 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla16
blocking-kilimanjaro +
Tracking Status
firefox16 - ---

People

(Reporter: jsmith, Assigned: johns)

References

Details

(Whiteboard: [Desktop WebRT], [qa!], [blocking-webrtdesktop1+])

Attachments

(2 files, 1 obsolete file)

The desktop web runtime needs the ability to configure the underlying core to only allow versions of flash to run within the runtime. All other plugins are planned to not be allowed within the runtime, although we should be ready to evolve and change quickly if we discover later down the line that we need to enable other plugins.

The implementation I heard discussed in today's apps meeting considered configuring a whitelist of the plugins that are allowed to run.

This is needed for the first release of the desktop web runtime (Fx 15).
Blocks: 755554
I can look into this, it shouldn't be very difficult
Assignee: nobody → jschoenick
Whiteboard: [Desktop WebRT]
Nominating for k9o - this is needed for the desktop web runtime to only enable flash in the runtime.
blocking-kilimanjaro: --- → ?
blocking-kilimanjaro: ? → +
jst, this has been called out as the correct implementation for bug 755554, can you confirm?
This adds plugin.allowed_types, which limits what MIME types plugins can claim (comma separated)

Right now it does not completely suppress (mark invalid) plugins that claim no valid types -- they'll be in the plugin registry, but will not be associated with any types or suffixes. We could suppress these, but that would mean that modifying this pref would require deleting pluginreg.dat
Flagging for tracking FF 16 - we need this for desktop web runtime 1st release
Comment on attachment 638498 [details] [diff] [review]
Implement plugin.allowed_types whitelist

Note that the 'IsTypeInPrefList' helper duplicates some nsPluginTag::RegisterWithCategoryManager code, which goes away with a patch on bug 751237 (it just makes sense to land this first)
Attachment #638498 - Flags: review?(joshmoz)
Attachment #638498 - Flags: review?(joshmoz) → review+
Comment on attachment 638498 [details] [diff] [review]
Implement plugin.allowed_types whitelist

>diff --git a/dom/plugins/base/nsPluginHost.cpp b/dom/plugins/base/nsPluginHost.cpp

>+nsPluginHost::IsTypeWhitelisted(const char *aMimeType)
>+{
>+  if (!Preferences::HasUserValue(kPrefWhitelist)) {
>+    return true;

This will mean that a default value of the preference won't be effective - isn't that what we need for bug 755554?
https://hg.mozilla.org/mozilla-central/rev/b6488e90d566
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
Whiteboard: [Desktop WebRT] → [Desktop WebRT], [qa-
Whiteboard: [Desktop WebRT], [qa- → [Desktop WebRT], [qa-]
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #7)
> This will mean that a default value of the preference won't be effective -
> isn't that what we need for bug 755554?

Bah, I intended that the whitelist not be enforced if it was empty, but clearly HasUserValue is not going to work if we're giving it defaults.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla16 → ---
Attachment #640453 - Flags: review?(joshmoz)
Comment on attachment 640453 [details] [diff] [review]
Followup, check if the preference has a value, not necessarily a user value

Why not just put the pref check in IsTypeInPrefList() itself, since it's already reading the pref anyways?
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #11)
> Comment on attachment 640453 [details] [diff] [review]
> Followup, check if the preference has a value, not necessarily a user value
> 
> Why not just put the pref check in IsTypeInPrefList() itself, since it's
> already reading the pref anyways?

IsTypeInPrefList is a helper to deduplicate code between this and the category manager changes in bug 751237, where we don't want to return true if the pref is empty. I can change it to just move the GetString call out of the helper for simplicity
Attachment #640453 - Attachment is obsolete: true
Attachment #640453 - Flags: review?(joshmoz)
Whiteboard: [Desktop WebRT], [qa-] → [Desktop WebRT], [qa-], [blocking-webrtdesktop1+]
Attachment #640476 - Flags: review?(joshmoz) → review+
https://hg.mozilla.org/mozilla-central/rev/686cf6e6ed4b
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
Should bugs be filed blocking this if we want to add other plugins to the whitelist? Silverlight for Netflix, for example.
(In reply to Reuben Morais [:reuben] from comment #16)
> Should bugs be filed blocking this if we want to add other plugins to the
> whitelist? Silverlight for Netflix, for example.

Enabling the whitelist in webrt was done in bug 755554, so that may be a better target
Verified through testing of bug 755554 for Win 7, OS X 10.7, and Ubuntu 12.
Status: RESOLVED → VERIFIED
Whiteboard: [Desktop WebRT], [qa-], [blocking-webrtdesktop1+] → [Desktop WebRT], [qa!], [blocking-webrtdesktop1+]
Attachment #638498 - Flags: checkin+
Attachment #640476 - Flags: checkin+
It seems like this bug missed the daily check for updates and is the cause of https://bugzilla.mozilla.org/show_bug.cgi?id=768521?
You need to log in before you can comment on or make changes to this bug.