| Not all network programs need to run code uploaded from remote systems, but those that do (applets, Java WebStart, agent hosts , distributed computers) need strong security protections . A lot of FUD (fear, uncertainty, and doubt) has been spread around about exactly what remotely loaded Java code, applets in particular, can and cannot do. This is not a book about Java security, but I will mention a few things that code loaded from the network is usually prohibited from doing. -
Remotely loaded code cannot access arbitrary addresses in memory. Unlike the other restrictions in the list, which are enforced by a SecurityManager , this restriction is a property of the Java language itself and the byte code verifier. -
Remotely loaded code cannot access the local filesystem. It cannot read from or write to the local filesystem nor can it find out any information about files. Therefore, it cannot find out whether a file exists or what its modification date may be. (Java WebStart applications can actually ask the user for permissions to read or write files on a case-by-case basis.) -
Remotely loaded code cannot print documents. (Java WebStart applications can do this with the user's explicit permission on a case-by-case basis.) -
Remotely loaded code cannot read from or write to the system clipboard. (Java WebStart applications can do this with the user's explicit permission on a case-by-case basis.) It can read from and write to its own clipboard. -
Remotely loaded code cannot launch other programs on the client. In other words, it cannot call System. exec ( ) or Runtime.exec( ) . -
Remotely loaded code cannot load native libraries or define native method calls. -
Remotely loaded code is not allowed to use System.getProperty( ) in a way that reveals information about the user or the user's machine, such as a username or home directory. It may use System.getProperty( ) to find out what version of Java is in use. -
Remotely loaded code may not define any system properties. -
Remotely loaded code may not create or manipulate any Thread that is not in the same ThreadGroup . -
Remotely loaded code cannot define or use a new instance of ClassLoader , SecurityManager , ContentHandlerFactory , SocketImplFactory , or URLStreamHandlerFactory . It must use the ones already in place. Finally, and most importantly for this book: -
Remotely loaded code can only open network connections to the host from which the code itself was downloaded. -
Remotely loaded code cannot listen on ports below 1,024. -
Even if a remotely loaded program can listen on a port, it can only accept incoming connections from the host from which the code itself was downloaded. These restrictions can be relaxed for digitally signed code. Figure 1-8 shows the dialog a Java WebStart application uses to ask the user for additional preferences. Figure 1-8. Java WebStart requesting the user allow unlimited access for remotely loaded code 
Even if you sign the application with a verifiable certificate so the warning is a little less blood-curdling, do not expect the user to allow connections to arbitrary hosts. If a program cannot live with these restrictions, you'll need to ask the user to download and install an application, rather than running your program directly from a web site. Java applications are just like any other sort of application: they aren't restricted as to what they can do. If you are writing an application that downloads and executes classes, carefully consider what restrictions should be put in place and design an appropriate security policy to implement those restrictions. |
