From Sean.Mullan at Sun.COM Mon Oct 1 19:53:45 2007 From: Sean.Mullan at Sun.COM (Sean Mullan) Date: Mon, 01 Oct 2007 15:53:45 -0400 Subject: [security-dev 00020]: Re: Retrieve the effective ProtectionDomains of a AccessControlContext? In-Reply-To: <46FA14AB.1060409@sun.com> References: <46FA14AB.1060409@sun.com> Message-ID: <47015049.2000005@sun.com> Weijun Max Wang wrote: > Hi Guys > > What's the best way to find out what ProtectionDomains are effective > currently (or for a given AccessControlContext)? > > For "effective", I mean those since the last doPrivileged call. > I think you could do that with a DomainCombiner, ex: - create an AccessControlContext with the DomainCombiner - call AccessController.doPrivileged with the AccessControlContext - when a security check occurs or when you invoke AccessController.getContext, your DomainCombiner can take a snapshot of the ProtectionDomains. --Sean From ncruces at gmail.com Fri Oct 5 12:56:46 2007 From: ncruces at gmail.com (Nuno Cruces) Date: Fri, 5 Oct 2007 13:56:46 +0100 Subject: [security-dev 00021]: Loading an unverified class Message-ID: <42d654a0710050556v40331695vbb06cee242464714@mail.gmail.com> Hi, First off, a little introduction, so I'm hopefully not considered heretic. I'm the (sole) developer of a project called JauVM (http://jauvm.sf.net/). This project implements a JVM bytecode interpreter in Java, which allows interpreted JVM code to use both tail-calls and continuations. Some examples of this can be found in: http://jauvm.svn.sf.net/viewvc/jauvm/trunk/jauvm/test/ Interpreted and "native" code can coexist and be freely mixed in one program. Methods tagged by the @interpretable annotation are interpreted by the JauVM, and all other methods are delegated to the underlying JVM (e.g.: Sun's; the JauVM is a Java program, that itself runs atop a JVM). For an example of this look at: http://jauvm.svn.sf.net/viewvc/jauvm/trunk/jauvm/test/Pythag.java?view=markup If you have any questions on the JauVM, feel free to ask, either on or off band. But now to the problem at hand. The interpreter calls "native" methods using reflection, which works in all but one situation: non-virtual calls on the super instance. Static methods, interface methods, virtual methods all work. Constructors and private methods, also work (private methods thanks to setAccessible), and are non-virtual. It doesn't seem possible, however, to make the non-virtual call to a public/protected method, required to implement invokespecial on the super instance. The only way I've been able to do this, is by generating a class at runtime, which is fine, except the verifier is quite strict, even on ACC_SUPER-less classes. For instance, the following two classes fail with "Illegal use of nonvirtual function call" and "Incompatible object argument for invokespecial", despite working flawlessly with "-noverify". class superA { public static void call(A a); %load a invokespecial A.fn()void return } } class superA extends A { public static void call(A a); %load a invokespecial A.fn()void return } } So, my question is, is it possible in any way to load specific classes at runtime bypassing the verifier? I understand this is a security issue, but so is (e.g.) accessing the Unsafe object, which you can do easily thanks to reflection and setAccessible (and my code already requires setAccessible to handle private members, as above). A non-portable solution (e.g., using Unsafe) would also help. I've tried Unsafe.defineClass, which seems to bypass some security checks, but not the verifier. Having the class be loaded by the null classloader seems to bypass verification, but then references to A above can't be resolved. If you have any other ideas on how to implement this, that would be a great help too, obviously. JNI is always a possibility and I'm interested in a JNI solution, but even then I would still rather have a bytecoded option available alongside (even if unportable, unsafe). Thank you all for your time and patience. If this is the wrong medium to ask such a question, I'm sorry. I'd still be glad if you could at least be so kind to point me in the right direction. Regards, Nuno Cruces PS: As a curiosity, the only other "similar" issue I've had implementing the JauVM is the need for unbalanced synchronization (which JVMs is allowed, but not required to accept). There, a combination of three implementations work to "solve" the problem: a pure Java version for those VMs that allow unbalanced syncronization; a Unsafe based version where available; a JNI version where available. I have a working prototype of this, it still isn't available in the project page. Thanks again! From tackline at tackline.plus.com Tue Oct 30 11:41:55 2007 From: tackline at tackline.plus.com (Thomas Hawtin) Date: Tue, 30 Oct 2007 11:41:55 +0000 Subject: [security-dev 00022]: Re: Loading an unverified class In-Reply-To: <42d654a0710050556v40331695vbb06cee242464714@mail.gmail.com> References: <42d654a0710050556v40331695vbb06cee242464714@mail.gmail.com> Message-ID: <47271883.4000406@tackline.plus.com> Nuno Cruces wrote: > > The interpreter calls "native" methods using reflection, which works > in all but one situation: non-virtual calls on the super instance. > Static methods, interface methods, virtual methods all work. > Constructors and private methods, also work (private methods thanks to > setAccessible), and are non-virtual. It doesn't seem possible, > however, to make the non-virtual call to a public/protected method, > required to implement invokespecial on the super instance. Not a direct answer, but there is one place in the JDK where this is done. Deserialisation requires calling the no-arg constructor of the most derived, non-Serializable class. Obviously you can't do this with the public reflection API or verifiable bytecode. So that would be a good place to start looking. Tom Hawtin (thomas.hawtin at sun.com)