You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Igor Bukanov <ba...@igor.fastmail.fm> on 2004/02/05 15:46:17 UTC
Rhino and BatikSecurityController
Hi!
Antoine Levy-Lambert has posted a message at
netscape.public.mozilla.jseng newsgroup about an incompatible change in
Rhino CVS tip that caused Batik to fail during compilation.
First, thanks for the error report, the changes in Rhino were supposed to
be backward-compatible and I will fix Rhino ASAP.
But I also looked at BatikSecurityController which implements
org.mozilla.javascript.SecurityController and that raised the second
issue.
BatikSecurityController does not have a proper implementation of
SecurityController.execWithDomain (or SecurityController.callWithDomain
which was introduced in Rhino CVS) method which allows trivially for
scripts from external URLs to be executed with permissions of local Batik
classes. For proper implementation of the interface please refer to
http://lxr.mozilla.org/mozilla/source/js/rhino/toolsrc/org/mozilla/javascript/tools/shell/JavaPolicySecurity.java
that contains a proper implementation of the interface.
I will try to create a version of it for Batik but it may take a week or
so. Is it ok?
Regards, Igor
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Rhino and BatikSecurityController
Posted by Igor Bukanov <ba...@igor.fastmail.fm>.
On Thu, 05 Feb 2004 14:38:23 -0500, "Thomas DeWeese"
<Th...@Kodak.com> said:
> ...
> Actually Batik gives the Rhino interpreter the class loader to use.
> So the class loader is from the Batik Context not the Rhino context.
> The Class loader also appears to associate an appropriate code source
> (i.e. the document's URL) with the created classes.
>
> > Now due to bugs in class loader implementations in many released JVMs
> > (Sun JVMs <= 1.4.1 that I checked has this bug) it also means that Rhino
> > code can potentially gain AllPermissions. This is in turn means that pure
> > JavaScript script can gain AllPermissions due to problematic
> > implementation of SecurityController.
>
> I guess I am unaware of these bugs - do they rely on being able
> to create a class loader? If so the Rhino code is not allowed to do
> so.
To be completely clear: the current implementation of
org.mozilla.javascript.SecurityController in Batik allows scripts to run
with the same permissions that Rhino classes have.
Here is extract from
./resources/org/apache/batik/apps/svgbrowser/resources/svgbrowser.policy
(other policy files have the same fragments) :
grant codeBase "${app.dev.base}/lib/js.jar" {
permission java.lang.RuntimePermission "createClassLoader";
permission java.net.SocketPermission "*", "listen, connect, resolve,
accept";
permission java.lang.RuntimePermission "accessDeclaredMembers";
permission java.util.PropertyPermission
"org.mozilla.javascript.JavaAdapter", "read";
permission java.util.PropertyPermission
"org.mozilla.javascript.JavaAdapterClassName", "read";
permission java.io.FilePermission "<<ALL FILES>>", "read";
};
Which means that Rhino classes and scripts they execute in the current
Batik can create class loaders, make arbitrary network connections and
read arbitrary files. If that is not enough, then the bugs in JVM
ClassLoader implementations means that scripts can gain AllPemissions as
long as they have "createClassLoader" permission.
>
> >>[*] This does have some unfortunate side effects like the debugger
> >>can only be used when 'secure scripting' is off - not usually a
> >>problem since most people debug there own code - but still annoying.
> >
> > What exactly the problem with it?
>
> The Debugger wants to access some properties it's not allowed to
> (home comes to mind).
But what about wrapping property access into
java.security.AccessController.doPrivileged() blocks? It should take of
the security exceptions.
Regards, Igor
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Rhino and BatikSecurityController
Posted by Thomas DeWeese <Th...@Kodak.com>.
Igor Bukanov wrote:
> On Thu, 05 Feb 2004 11:03:36 -0500, "Thomas DeWeese"
> <Th...@Kodak.com> said:
>
>>... however my
>>understanding is that script security is implemented using the Java
>>2 Security model in particular it puts _all_ the rhino classes in the
>>sand box[*]. I'm sure that a second set of eyes looking at this to
>>make sure we are doing it correctly would be greatly appreciated.
>
>
> This can not be true as far as I can see. From Rhino usage in
> RhinoInterpreter it follows that Batik uses the default compilation mode
> in Rhino that compiles JavaScript to JVM bytecode, loads the generated
> classes and then let JVM execute them. It means that Rhino classes can at
> least create ClassLoader instances.
Actually Batik gives the Rhino interpreter the class loader to use.
So the class loader is from the Batik Context not the Rhino context.
The Class loader also appears to associate an appropriate code source
(i.e. the document's URL) with the created classes.
> Now due to bugs in class loader implementations in many released JVMs
> (Sun JVMs <= 1.4.1 that I checked has this bug) it also means that Rhino
> code can potentially gain AllPermissions. This is in turn means that pure
> JavaScript script can gain AllPermissions due to problematic
> implementation of SecurityController.
I guess I am unaware of these bugs - do they rely on being able
to create a class loader? If so the Rhino code is not allowed to do
so.
>>[*] This does have some unfortunate side effects like the debugger
>>can only be used when 'secure scripting' is off - not usually a
>>problem since most people debug there own code - but still annoying.
>
> What exactly the problem with it?
The Debugger wants to access some properties it's not allowed to
(home comes to mind).
>
> Regards, Igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Rhino and BatikSecurityController
Posted by Igor Bukanov <ba...@igor.fastmail.fm>.
On Thu, 05 Feb 2004 11:03:36 -0500, "Thomas DeWeese"
<Th...@Kodak.com> said:
>
> ... however my
> understanding is that script security is implemented using the Java
> 2 Security model in particular it puts _all_ the rhino classes in the
> sand box[*]. I'm sure that a second set of eyes looking at this to
> make sure we are doing it correctly would be greatly appreciated.
This can not be true as far as I can see. From Rhino usage in
RhinoInterpreter it follows that Batik uses the default compilation mode
in Rhino that compiles JavaScript to JVM bytecode, loads the generated
classes and then let JVM execute them. It means that Rhino classes can at
least create ClassLoader instances.
Now due to bugs in class loader implementations in many released JVMs
(Sun JVMs <= 1.4.1 that I checked has this bug) it also means that Rhino
code can potentially gain AllPermissions. This is in turn means that pure
JavaScript script can gain AllPermissions due to problematic
implementation of SecurityController.
>
> [*] This does have some unfortunate side effects like the debugger
> can only be used when 'secure scripting' is off - not usually a
> problem since most people debug there own code - but still annoying.
What exactly the problem with it?
Regards, Igor
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Rhino and BatikSecurityController
Posted by Thomas DeWeese <Th...@Kodak.com>.
Igor Bukanov wrote:
> Antoine Levy-Lambert has posted a message at
> netscape.public.mozilla.jseng newsgroup about an incompatible change in
> Rhino CVS tip that caused Batik to fail during compilation.
>
> First, thanks for the error report, the changes in Rhino were supposed to
> be backward-compatible and I will fix Rhino ASAP.
That would be great!
> But I also looked at BatikSecurityController which implements
> org.mozilla.javascript.SecurityController and that raised the second
> issue.
>
> BatikSecurityController does not have a proper implementation of
> SecurityController.execWithDomain (or SecurityController.callWithDomain
> which was introduced in Rhino CVS) method which allows trivially for
> scripts from external URLs to be executed with permissions of local Batik
> classes.
Vincent Hardy is the 'security architect' for Batik, however my
understanding is that script security is implemented using the Java
2 Security model in particular it puts _all_ the rhino classes in the
sand box[*]. I'm sure that a second set of eyes looking at this to
make sure we are doing it correctly would be greatly appreciated.
[*] This does have some unfortunate side effects like the debugger
can only be used when 'secure scripting' is off - not usually a
problem since most people debug there own code - but still annoying.
> For proper implementation of the interface please refer to
> http://lxr.mozilla.org/mozilla/source/js/rhino/toolsrc/org/mozilla/javascript/tools/shell/JavaPolicySecurity.java
> that contains a proper implementation of the interface.
> I will try to create a version of it for Batik but it may take a week or
> so. Is it ok?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org