Home     |     Java    |     Php General    |     Oracle Database    |     Oracle Server  

MS Dynamics CRM 3.0

  •  Setting up and Configuring Microsoft Dynamics CRM 3.0
  •  Managing Security and Information Access
  •  Entity Customization: Concepts and Attributes
  •  Entity Customization: Forms and Views
  •  Entity Customization: Relationships, Custom Entities, and Site Map
  •  Reporting and Analysis
  •  Workflow
  •  Server-Side SDK
  •  Client-Side SDK
  •  Integration with External Applications
  • Cervo Technologies
    The Right Source to Outsource

    Sharepoint Portal Server KB

    Microsoft CRM Info

    WPF Interview Questions

    SilverLight Interview Qs

    Asp.Net 2.0 Interview Qs

    Asp.NET 1.1 FAQs

    Oracle Interview Questions

    SAP Interview Questions

    Java Programming

    javax.scripting, Rhino, and creating sandboxes...


    I'd like to be able to control the interaction between my script and
    the host Java environment.  Most specifically, if I don't explicitly
    allow something, it shouldn't be available to the script context.

    Is there an easy-and-sure way to do that? Do I need to go through the
    trouble of setting up a SecurityManager?  Can I get away with a
    "clever" Bindings implementation?  I'm mostly interested in Rhino,
    which comes shipped with the JDK 1.6, but if there is a general
    approach, that'd be great too.

    Thanks,
    Daniel.

    Daniel Pitts wrote:
    > I'd like to be able to control the interaction between my script and
    > the host Java environment.  Most specifically, if I don't explicitly
    > allow something, it shouldn't be available to the script context.

    > Is there an easy-and-sure way to do that? Do I need to go through the
    > trouble of setting up a SecurityManager?  Can I get away with a
    > "clever" Bindings implementation?  I'm mostly interested in Rhino,
    > which comes shipped with the JDK 1.6, but if there is a general
    > approach, that'd be great too.

    I believe (use at your own risk) that for the Java SE 1.6 adaptation of
    Rhino supplied in the Sun implementation (it's not a required part, and
    may be implemented differently), you can get away with calling the
    scripting API with lowered permissions. You will, of course, need a
    SecurityManager. Remember JavaScript is still code. Running untrusted
    code safely is difficult.

    Where ever you use the API, surround the code with the usual two
    argument java.security.AccessController.doPrivileged. Supply an acc with
    the required (lack of) permissions (not null!). The Sun Rhino JavaScript
    implementation will capture and then reapply those permission for
    callback interfaces.

    You will need to keep scripts away from code that is not secure. That
    means, for instance, using a completely separate class loader (and set
    something as thread context class loader). If you use AWT, you will need
    to set up a separate AppContext (which you can't do portably).

    Actually, it's a bit of a nightmare. I wouldn't bother. ;)

    Rhino itself is a different kettle of fish, and not for the better. I
    think you should be able to get away with applying the permissions to
    the Rhino classes. Not entirely sure it will run like that - certainly
    the optimiser wont work.

    Tom Hawtin

    [Cross-posted and followup-to: comp.lang.java.security]

    Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc