Operating on the Security Manager

writeFileDescriptor . The second succeeds if the current protection domain has a file permission with a name that matches the given file and an action of write. public void checkDeleteString file Check whether the program is allowed to delete the given file. This succeeds if the current protection domain has a file permission with a name that matches the given file and an action of delete. Interestingly, although as developers we tend to think of other file operations −− such as creating a file or seeing when the file was last modified −− as being distinct operations, as far as security is concerned, the Java API considers all operations to be either reading, writing, or deleting. Table 4−1 lists the Java API interaction with the checkRead , checkWrite , and checkDelete methods, listing when and why each check is invoked. In all the tables in this chapter, the syntax may imply that the calling methods are all static, but it of course is not the case: the entry File.canRead means the canRead method invoked on an instance of the File class. This table lists only those classes that directly call the security manager method in question. There may be many routes through the Java API that lead to one of these checks; for example, when a FileReader object is constructed, it will construct a FileInputStream object, which will result in a call to checkRead . Table 4−1. Check Methods Method Called By Rationale checkRead File.canRead Test if the current thread can read the file. FileInputStream RandomAccessFile Constructing a file object requires that you read the file. File.isDirectory File.isFile Determining whether a file object is an actual file or a directory requires that you read the file. File.lastModified Determining the modification date requires that you read the files attributes. File.length Determining the length requires that you read the files attributes. File.list Determining the files in a directory requires that you read the directory. checkWrite File.canWrite Test if the current thread can write the file. FileOutputStream RandomAccessFile To construct a file object, you must be able to write the file. File.mkdir To create a directory, you must be able to write to the filesystem. File.renameTo To rename a file, you must be able to write to the directory containing the file. File.createTempFile To create a temporary file, you must be able to write the file. checkDelete File.delete Test if the current thread can delete a file. File.deleteOnExit Test if the current thread can delete the file when the virtual machine exits. 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