Subj : Again: Security Problem
To   : netscape.public.mozilla.jseng
From : Keno Albrecht
Date : Thu Jul 08 2004 11:16 pm

Hello again :-),

My previous question with another flavor... This is really serious, I 
hope to encourage some discussion. I tried everything on Windows XP, 
Mozilla 1.7, and JDK 1.4.2/1.5b2.

Why can I write something like

var fos = new java.io.FileOutputStream(new java.io.File("somefile.txt"));

in a mozilla plugin (e.g. on clicking a xul-button) and use it without 
any problem/without any SecurityExceptions thrown, that is: e.g. write 
to that file, but

var customObject = new Packages.my.own.CustomClass();

where my.own.CustomClass() is in the classpath (but not in [jre]/classes 
or [jre]/lib/ext) and contains something like this:

public void CustomClass() {
   try {
     FileOutputStream fos = new FileOutputStream(new File("somefile.txt"));
   } catch (Exception e) {
     System.out.println("Annoying SecurityException thrown");
   }
}

???

I mean: Obviously, these are two different approaches to handle Java 
classes, resp., two different SecurityManagers used:
1) In the first example (JavaScript only/no custom class), there is no 
restriction/no SecurityManager set --- I can do anything I want, e.g. 
"format c:"...
2) In the second example (with custom class), the custom class is put 
into an "Applet-Sandbox", I cannot access the local harddisk (a 
SecurityException is thrown), I cannot open an arbitrary connection, 
Frames are marked with an "Applet"-Tag in the bottom etc.

To make it even a little stranger: When I create a FileOutputStream just 
like before

var fos = new java.io.FileOutputStream(new java.io.File("somefile.txt"));

and then use a custom class like this

var customObject = new Packages.my.own.CustomClass(fos);

I can do something like

public void CustomClass(FileOutputStream fos) {
   try {
     fos.write(0);
   } catch (Exception e) {
     // NO SecurityException will be thrown
   }
}


Well, I think this is not the way it should work. In my opinion, the 
first approach is ok, because I can also harm the system with JavaScript 
alone (and I hope it's not a security bug...). Therefore, this approach 
should also be applied to custom classes, that is, when I use a custom 
class I don't want any restrictions, no SecurityManagers at all.

NO SECURTY FOR CUSTOM JAVA CLASSES??
Yes! The code I'm talking about is part of a Mozilla extension. That 
means that a user actively and intentionally installed a .xpi file where 
he/she clicked "ok" to trust it. As said before, by using JavaScript, I 
can also crash the system in (almost) anyway I want. Thus, I do not see 
any reason why my code should run in a restricted applet sandbox?

Thanks for discussing this, or maybe telling me how to handle this :-),
Keno


PS: (I put this here to make things not even more confusing...)

Does anybody tried something like this (using custom classes) before? 
LiveConnect (Java<->JavaScript interface) exists for a couple of years 
now, but I heard nobody talk about problems like this before? (In fact, 
I think that it doesn't work before Mozilla 1.7 at all... see 
http://bugzilla.mozilla.org/show_bug.cgi?id=246224)

To get my custom class into the classpath I tried several things. If I 
use a URLClassLoader in the JavaScript code to load my custom class, it 
works quiet fine, but I have the mentioned security problems. If I use 
the Java Control Panel to change the class path by adding something like 
"-cp=x:\path\to\my\own\CustomClass.jar" to the runtime parameters, my 
class is also found but has the same problems. When I use 
"-Xbootclasspath/p:x:\path\to\my\own\CustomClass.jar" instead, 
everything is fine, I can access the disk, open connections etc. So it 
seems that the SecurityManager is applied to classes outside the 
bootclasspath only.
I can also put my .jar file to the [JRE]/lib/ext directory, because this 
is also on the bootclasspath as far as I know (some strange 
MalformedURLException is thrown, but everything is working fine). And 
[JRE]/classes is working for classes (no .JARs), too.

So where is the problem? It would be fine if I could change the 
bootclasspath within the install.js or the javascript part of my plugin, 
but currently I don't know if this is possible at all and, if possible, 
if it does work on all plattforms. But anyway (again), this is not the 
way it should work, e.g. changing the bootclasspath or copy something to 
the existing JRE-classpath might be something that can be done by an 
administrator only?!

I just want my Java code to run without any security restrictions, 
because there is no reason for doing that :-)

.