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

Status: VERIFIED FIXED

(Core :: Security: CAPS, enhancement, P1)

Description

[Andrew Brygin]

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

[Andrew Brygin]

Attachment: The implementation of propoused solution.

Comment 2

[Andrew Brygin]

  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

[Mitchell Stoltz (not reading bugmail)]

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. 

Comment 4

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 6

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Target is now 0.9.4, Priority P1.

Comment 8

[Mitchell Stoltz (not reading bugmail)]

Moving this out to 0.9.5 so I'll have time to do it right.

Comment 9

[Mitchell Stoltz (not reading bugmail)]

time marches on...retargeting to 0.9.6

Comment 10

[Mitchell Stoltz (not reading bugmail)]

performance, footprint, feature work, and re-architecture bugs will be addressed
in 0.9.8

Comment 11

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 12

[bsharma]

Marking verified as per above developer comments.