Fine-grained control of JS access to plugins is needed.

VERIFIED FIXED in mozilla0.9.8



18 years ago
17 years ago


(Reporter: bae, Assigned: security-bugs)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
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.

Comment 1

18 years ago
Created attachment 29027 [details] [diff] [review]
The implementation of  propoused solution.

Comment 2

18 years ago
  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).

Comment 3

18 years ago
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. 
Depends on: 71996
Ever confirmed: true
Target Milestone: --- → mozilla1.0

Comment 4

18 years ago
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, This goes right to the heart of the changes
I'll be making in caps soon.

Comment 5

18 years ago
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

Comment 6

18 years ago
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


18 years ago
Priority: -- → P2
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 7

17 years ago
Target is now 0.9.4, Priority P1.
Priority: P2 → P1
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 8

17 years ago
Moving this out to 0.9.5 so I'll have time to do it right.
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 9

17 years ago
time marches on...retargeting to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 10

17 years ago
performance, footprint, feature work, and re-architecture bugs will be addressed
in 0.9.8
Target Milestone: mozilla0.9.6 → mozilla0.9.8

Comment 11

17 years ago
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.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 12

17 years ago
Marking verified as per above developer comments.
You need to log in before you can comment on or make changes to this bug.