It would be nice to have more fine-grained control of plugin access permission granting policy for JS code. At the moment the only way to control JS code access to the plugin is to use the "security.xpconnect.plugin.unrestricted" property and the standard control of XPConnect usage permissions for JS code. It would be nice to be able to use this fine-grained control to grant permissions for plugin access only for that JS code which was loaded from trusted sites or JS code with trusted signature. The concrete permission granting policy is up to plugin developer, but we need means to implement such policy on plugin side. The scenario i have in mind is following: - browser security subsystem checks whenever plugin implements own security policy (supports some interface) (if not then standard permission check procedure will be used) - if plugin has own policy then information about origin and signature of JS code in question is passed to plugin to make a decision whenever JS code is "trusted". This decision is further used by browser security subsystem.
I just attached proposed solution that implements follow scenario: If object to be accessed supports nsIAccessCheckedPlugin interface then we extract the origin and certificate attributes for the JS code in question and ask plugin for decision. If plugin decision is "AskUser" then we bring up confirmation dialog and store user decision for further usage. To be able to obtain certificate attributes we store them (after signature verification) in CertificatePrincipal using nsICertificateAttributes interface. Therefore proposed solution require small change in psm-glue module (we additionally read several certificate attributes).
Glad you asked. Fine-grained access control for all XPConnect interfaces is coming soon, as part of the DOM-to-XPConnect change. Allowing plugins to advertise their own security policy would be a small addition, so I'm marking the dependency here.
Status: UNCONFIRMED → ASSIGNED
Depends on: 71996
Ever confirmed: true
Target Milestone: --- → mozilla1.0
Thanks for the code, but let's wait for thenew XPConnect security architecture before making changes here. Hopefully we won't need a separate interface just for plugins to advertise their security policy. As for certificate attributes, these are all stored in PSM's cert database, of course, and I'd like to avoid duplicating all of that data in caps, and in caps prefs. Instead, certificate principals just keep a unique ID for the cert. With PSM 2.0, we should be able to access the rest of the cert attributes directly and not have to copy them all into the caps principal database. We should discuss general strategy on the newsgroup, netscape.public.mozilla.security. This goes right to the heart of the changes I'll be making in caps soon.
I've worked out with the Sun folks how we're going to do this, and they need it for 0.9.1. All it requires is a change to nsISceurityCheckedComponent - and making sure signed scripts work.
Target Milestone: mozilla1.0 → mozilla0.9.1
I'm not going to have time to do the API change (adding principals as a parameter to the functions of nsISecutiryCheckedComponent) but you can get the same functionality by calling nsScriptSecurityManager::GetSubjectPrincipal. I'm hoping signed scripts will be working for the beta, but if they aren't, there's no breach of security - you just won't be able to use signed scripts to script the plugin. I'll have it working by RTM of NS6.5.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Priority: -- → P2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target is now 0.9.4, Priority P1.
Priority: P2 → P1
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Moving this out to 0.9.5 so I'll have time to do it right.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
time marches on...retargeting to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
performance, footprint, feature work, and re-architecture bugs will be addressed in 0.9.8
Target Milestone: mozilla0.9.6 → mozilla0.9.8
I haven't heard anything from the Sun folks on this in a long time, so I'm going to assume they have the interfaces they need. The security model for scriptable plugins is still a bit up in the air, but we've got a workable model for now, I think, so I'm going to close this bug. If anyone has specific problems with plugin scriptability, please file separate bugs.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Marking verified as per above developer comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.