begin quoting Wade Curry as of Mon, Aug 01, 2005 at 05:59:14PM -0700: > Stewart Stremler said: > > [big snip] > > Java-style exceptions are nice (I've been playing with running > > stuff in a Java sandbox). Although... a lot of open-source java > > programmers seem enamoured of using their own classloader for > > some unknown reason. And allowing arbitrary classloaders breaks > > the sandbox. Just because I *know* what is causing the error doesn't > > mean it's always fixable... > > [another big snip] > > I'm hoping for some elucidation here. I'm not sure I know what a > class loader is.
The compiler tokenizes and preprocesses the source code into the bytecode (the VM's machine code, essentially). A classloader takes the bytecode for a class from some source -- local disk, network connection, or whatnot -- and loads it into the system, initializing as appropriate. > It sounds like something that would be an integral > part of the VM, and a difficult thing to get around. Well, that's where flexibility runs into security. Because Java doesn't put all of the classloading in the VM, it's relatively simple to load classes via a url, over the network. Thus, applets become really easy to do. (Plus other "neat" things become easy for third-party vendors to do -- mobile code; in-memory runtime compilation and execution (nice for IDEs); runtime upgrades; embedded systems loading code via JNI; etc.) You can do the same sort of thing in C, except that C doesn't make it easy, and C doesn't have any runtime security mechanisms to subvert. > I'm also not sure how the sandbox environment works, so I'm left > wondering why a customized class loader would break it. A sandbox works by saying "no, you can't do that". Trusted -- by the VM -- code can do a lot of things that untrusted code shouldn't. You can tell the Java VM that its program doesn't have read access to the filesystem, although the VM will read from that same filesystem to load the class files for that program. If the flow of control passes through the untrusted code, and then back into the trusted code, it's not trusted anymore (except at specific points where the flow of control is trusted again). Code-injection exploits are a lot harder, without giving up callbacks. A custom classloader may define protection domains for the classes it loads... and thus, code loaded by that classloader may be marked as "trusted". When you let user-level code mark other code as 'trusted', you have a problem. It's like letting a user use chown and chmod on their own scripts to make 'em setuid and owned by root. -Stewart "Not a thing you want user-level code to require." Stremler
pgpG2q5bUAoen.pgp
Description: PGP signature
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
