Subj : Re: Again: Security Problem
To   : Brendan Eich
From : Keno Albrecht
Date : Fri Jul 09 2004 01:29 pm

> Are you using chrome: URLs to load XUL for both these testcases, or for 
> neither?  If you're using chrome: for the first, but not the second, 
> that should cause different results (chrome: is trusted).  But surely 
> that is too simple a theory....

"chrome:" in both cases, the same js-file, but different buttons...

Keno



> 
> Cc'ing LiveConnect folks.
> 
> /be
> 
> 
>> 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 :-)

.