If you carefully considered the list of methods in the table above, you were probably surprised not to see an obvious method to check: the actual
read or
write methods of any of the
File classes. The
assumption here is that a trusted class is responsible for determining the security policy associated with any particular
File object; if the trusted class decides that it is okay for an untrusted class to perform IO on a
particular FileStream
object, then it is free to deliver that object to the untrusted class, and the untrusted class is free to read or write to that object. This implementation also allows for much greater efficiency: if the
program had to check with the security manager every time it called the read
or write
methods, IO performance would drastically suffer.
4.3.2 Methods Relating to Network Access
Network access in Java is always accomplished by opening a network socket, whether directly through the Socket
class or indirectly through another class like the URL
class. An untrusted class can only by default open a socket to the machine from which it was actually downloaded; typically, this is the location given by
the CODEBASE
tag in the HTML for the browser page containing the applet or −− in the absence of such a tag −− the web server for the page. In either case, the machine in question is a web server, so well use that
terminology in this discussion. Untrusted classes loaded from the classpath cannot, by default, open any sockets.
This restriction on untrusted classes is designed to prevent two types of attack. The first attack concerns a rogue applet using your machine for malicious purposes by connecting to a third machine over the network.
The canonical description of this attack is an applet that connects to the mail server on someone elses machine and sends people on that machine offensive email from your address. There are more severe attacks
possible with this technique, however −− such an applet could use a connection from your machine to break into a third computer, and auditors on that third computer will think the break−in attempts are coming from
you, which can cause you all sorts of legal problems.
The second sort of attack concerns network information on your local network that you might not want to be broadcast to the world at large. Typically, computers at corporations or campuses sit behind a firewall so that
users on the Internet cannot access those computers see Figure 4−2. The firewall allows only certain types of traffic through e.g., HTTP traffic so that users on the local network can access the Internet, but users on the
Internet cannot glean any information about the local network.
Figure 4−2. A typical firewall configuration
Now consider what happens if an applet downloaded onto a machine on the local network can connect to other machines on the local network. This allows the applet to gather all sorts of information about the local
network topology and network services and to send that information via HTTP, so that it will pass through 60
the firewall back out onto the Internet. Such an opportunity for corporate spying would be very tempting to would−be hackers. Worse, if the applet had access to arbitrary network services, it could break into the local
HR database and steal employee data, or it could break into a network file server and steal corporate documents. Hence, applets and untrusted classes in general are prevented from arbitrary network access.
Network sockets can be logically divided into two classes: client sockets and server sockets. A client socket is responsible for initiating a conversation with an existing server socket; server sockets sit idle waiting for these
requests to come from client sockets. Untrusted classes are by default restricted from creating server sockets.
[2]
Normally, this is not a problem: since an applet can only talk to its web server, it could only answer requests from that machine −− and the applet can already open a connection to that machine at will. Theres no
algorithmic or logistic reason why an operation between the applet and the web server cannot always start with the applet as the client.
[2]
Technically, untrusted classes by default can create a server socket, since the default policy file allows all classes to perform the listen action. Once created, however, the server socket
must accept a connection on the socket, and that action is by default denied. The security manager uses the following methods to check network access:
public void checkConnectString host, int port public void checkConnectString host, int port, Object context
Check if the program can open a client socket to the given port on the given host. This succeeds if the current protection domain has a socket permission with a name that matches the host and port and an
action of connect.
public void checkListenint port Check if the program can create a server socket that is listening on the given port. The protection
domain must have a socket permission where the host is localhost, the port range includes the given port, and the action is listen.
public void checkAcceptString host, int port Check if the program can accept on an existing server socket a client connection that originated
from the given host and port. The protection domain must have a socket permission where the host and port match the parameters to this method and an action of accept.
public void checkMulticastInetAddress addr public void checkMulticastInetAddress addr, byte ttl
Check if the program can create a multicast socket at the given multicast address optionally with the given time−to−live value. This succeeds if the current protection domain has a socket permission
with a host that matches the given address, a port range of all ports, and an action list of connect and accept.
public void checkSetFactory Check if the program can change the default socket implementation. When the
Socket class is used
to create a socket, it gets a new socket from the socket factory, which typically supplies a standard TCP−based socket. However, a program could install a socket factory so that the sockets it uses all
have different semantics, such as sockets that send tracing information when they write data. The Chapter 4. The Security Manager
current protection domain must carry a runtime permission with the name setFactory
. The instances where these methods are used and the rationale for such uses are shown in Table 4−2.
Table 4−2. Security Manager Methods to Protect Network Access
Method Called By
Rationale
checkConnect DatagramSocket.send
DatagramSocket.receive Deprecated
MulticastSocket.send Socket
Test if the untrusted class can create a client−side connection.
checkConnect DatagramSocket.getLocalAddress
InetAddress.getHostName InetAddress.getLocalHost
InetAddress.getAllByName
Test if the untrusted class can see any hosts on the local network.
checkListen DatagramSocket
MulticastSocket ServerSocket
Test if the untrusted class can create a server−side socket.
checkMulticast DatagramSocket.send
DatagramSocket.receive MulticastSocket.send
MulticastSocket.receive MulticastSocket.joinGroup
MulticastSocket.leaveGroup
Test if the untrusted class can operate on a multicast socket.
checkAccept ServerSocket.accept
DatagramSocket.receive
