Security

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 tutorial 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 apps 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 apps 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 apps 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 tutorial:

• 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. Screenshot-8 shows the dialog a Java WebStart app uses to ask the user for additional preferences.

Screenshot-8. Java WebStart requesting the user allow unlimited access for remotely loaded code

Even if you sign the app 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 app, rather than running your program directly from a web site. Java apps are just like any other sort of app: they aren't restricted as to what they can do. If you are writing an app that downloads and executes classes, carefully consider what restrictions should be put in place and design an appropriate security policy to implement those restrictions.