Objective 11.1: Select from a list security restrictions that Java 2 environments normally impose on applets running in a browser

Applets require the installation of their own security manager, by the browser vendor. In general, since you do not know who you are downloading an Applet from, they are considered 100% untrustworthy and run in a ‘sandbox’. The sandbox allows the executable code to run on the client’s machine but with restrictions on what it can do. The sandbox prevents applets from:

• accessing the file system
• opening sockets to destinations other than the IP address from which it originated.
• acting as a socket server
• accessing some system properties
• starting other programs on the client
• making native calls
• creating new ‘trusted’ windows
• installing their own class loader or security manager.
• no restriction on memory or CPU usage though, can create lots of threads.

Authentication of the signed classes (only one needs to be to be considered a ‘signed applet’) downloaded. The authentication is to check they have not been replaced during transmission by a malicious attacker. There needs to be a certificate to sign the classes with. The ‘trusted’ classes is then allowed (without restriction in Java 1.1 and via the policy file in Java 1.2) to perform operations outside of the sandbox. The process to developing and shipping a trusted class is:

• Interacting with the security model, that is; calling specific operations to enable or disable privileges.
• Packaging the trusted class in a JAR (Netscape) or CAB (IE) file. JAR files are created using the ‘jar’ program and CAB files using the ‘cabarc’ or ‘dubuild’ programs.
• Get a digital certificate from a CA or a self-issued certificate for testing purposes.
• Sign the trusted class or its container with the certificate. The signature assures the receiver that someone is accountable for it’s actions.
Message digests created by the signing tool verifies that the class or container is unchanged since it was signed. To sign use the ‘signtool’ (Netscape), ‘signcode’ (IE) or ‘jarsigner’ (JVM).
• Configure the environment (Browser) to grant the ‘trusted’ class permission. Either through the browser config or java.policy file.

Creates a ‘.java.policy’ file that grants permissions to Applet, thus allowing Applets to do more, held on client’s normally PC in user’s home directory. The file is collection of policy entries, entries list permissions for a code source (URL), many specify a location of a key-store of keys to check signed classes against. Implements the ‘principal of least privilege’ – give application only the privileges that is needs to carry out its functions and no more.