Java Network Programming (3rd ed) [Electronic resources] نسخه متنی

1.2 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 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.