Would it be possible to add an option so that an environment is returned that does not have `print`, `load`, etc? This way application developers do not need to keep up with the list of things that need to be removed as that list changes in the future.
Peter On 2014-01-20, at 10:56 PM, "A. Sundararajan" <[email protected]> wrote: > Nashorn is secure. An untrusted script is runs in sandboxed mode (assuming > you turned security manager on). > > Nashorn prevents sensitive operations (including even Java reflection, jsr292 > access) from scripts without permissions. Starting with --no-java ensure no > java access at all. I suggested this - not as a security measure, but as > preference/option > > The ones that are left out after --no-java are only 'print', > 'load/loadWithNewGlobal/quit/exit' (loads script from file/URL) etc. -- all > require necessary permissions - except for print which basically prints to > the ScriptContext's output writer. For example, load will throw > SecurityException if sandbox script tries to load script from the internet. > > AFAIK, many implementations add one or two things to global scope. That in > itself is not a security problem -- it is how the security access check is > done even in the presence of extension objects and functions. > > -Sundar > > On Tuesday 21 January 2014 11:19 AM, Peter Michaux wrote: >> Thanks for your response. >> >> I'm surprised that I need to delete global host objects in order to get an >> empty environment. JavaScript is intended to be used as the scripting >> language for a wide variety of situations. One such situation is executing >> third party scripts in a secured sandbox. By requiring me to delete a known >> set of globals before executing a third party script there is a potential >> security hole. I might miss deleting one global especially if more default >> globals are added in the future. >> >> The C implementations of JavaScript do not have this issue. When an engine >> is created it is empty and it is up to me to add any host object that I >> want. I'll never be surprised by any host objects being added by default. >> >> Peter >> >> On 2014-01-20, at 10:24 PM, "A. Sundararajan" >> <[email protected]> wrote: >> >>> Hi, >>> >>> You can start your application with the System property >>> >>> -Dnashorn.args=--no-java >>> >>> This will avoid initializing properties needed for Java access ("Packages", >>> "Java", "java", "javax" etc.). Note that the script can access Java >>> methods/properties of objects explicitly exposed via >>> javax.script.ScriptContext/Bindings (if any). If those are also empty, then >>> global scope gets nothing from Java. >>> >>> Note this still defines certain extensions like 'load' , 'print' in global >>> scope as well as "context" (required per jsr223 spec). If you want, you can >>> manually delete these properties or assign undefined to these by writing a >>> simple init script that is loaded upfront - before running the actual >>> script. >>> >>> Hope this helps, >>> -Sundar >>> >>> On Tuesday 21 January 2014 10:45 AM, Peter Michaux wrote: >>>> Hi, >>>> >>>> When I create a new Nashorn script engine, it seems to come preloaded with >>>> globals like `print` which are not part of the ECMAScript standard. How >>>> can I create an "empty" environment that only has the globals defined in >>>> the standard? >>>> >>>> Thanks, >>>> Peter >
