Fundamental goals of security

·         protection of data from unauthorized reading or modification,

·         protection of computer resources against unauthorized use, and

·         guaranteeing correctness and availability of resources and data for authorized persons and entities

Downloaded Code, Applets, and the Java Security Manager

• Java doesn't apply security rules specifically to instances of subclasses of the java.applet.Applet class. Rather, it uses a security manager to apply rules to all classes
• Generally, the security manager applies restrictions to all classes except those that are loaded from the system's boot classpath
• The boot classpath is the list of locations from which core classes are loaded. Usually, this is restricted to the jarfiles in the directory jre/lib under the main Java installation
• In a Java application, the security manager is not installed unless you deliberately install it.
• using System.setSecurityManager(new SecurityManager());] or
•  from the command line [using java -Djava.security.manager].
• If code is running in a browser, it is important that the security manager should be installed by default, and that is handled by the browser itself.

What Does the Security Manager Prohibit?

• The security manager works by checking whether a particular permission is granted to the requesting class
• A permission is represented by a class describing the general permission
• Instances of the permission class describe the permission in more detail by adding a name and an action. The name and action are optional in some permission classes, but when used, they qualify the exact behavior that is to be allowed. For example, the permission class java.io.FilePermission can be granted with the name “read” and the action “/tmp/*”. This grants permission to read any file in the /tmp directory (but not subdirectories).
• The permission mechanism is extensible, so you can add new permissions

Permitted Operations to the Untrusted Code (applets) :

• ability to create a thread,
• limited ability to manipulate threads in the thread group that the browser created for the applet,
• ability to perform essential manipulation of the AWT event queue so that a GUI operates correctly,
•  limited ability to read but not modify some system properties.
• Generally permitted to make network connections to the host from which it was loaded.

Why the applet is prevented from connecting to other hosts

1.        If an applet could make arbitrary connections to any hosts, then applets could be used as the origin for denial of service attacks against other systems.

2.        However, the original reason that arbitrary network connections are prohibited is simply that many systems grant privileges to network requests based on the origin IP address of that request. If an applet could connect to arbitrary hosts, it would be possible for it to connect to a server inside your corporate network. If that server grants access to your machine based on IP address, then it will grant access to the applet, because it is sending requests from your machine. The applet could then obtain sensitive information and pass it back to its author, which you do not want to allow.

Denied Operations:

• Any operation that might be used to compromise the host is denied. The only exceptions to this are
• CPU usage, Memory usage, and Network bandwidth usage.
• Although an applet can read keystrokes that are sent to it, it should not be able to read keystrokes that are intended for other parts of the browser or other programs running on the host system.
• Although applets can make normal TCP/IP connections only with the host from which they were loaded, it is possible for them to send data to any cooperating host on the Internet

Java WebStart

• provides all the benefits of applets and addresses the problems that make applets less than satisfactory
• simplifies corporate system maintenance and thereby enhances security
• Java WebStart provides a small window that presents icons in a manner similar to a Windows desktop. These icons do not necessarily describe installed applications, but are typically links to code on a Web server  somewhere
• When you launch one of the applications shown in the Java WebStart desktop, the classes needed to run that application are downloaded from the Web server. This behavior is similar to that of an applet. However, once downloaded, the classes are stored locally. This allows for a faster startup on subsequent uses of the application.
• Better yet, each time you try to run that application, the system checks to see if any updates are available on the Web server, and if any updates exist, just the needed changes are downloaded. This ensures that the application is always ready to run, even if your computer is not connected to the network, while also ensuring that the most up-to-date version possible is used.
• the most significant feature of Java WebStart is that it provides a modified sandbox model. Specifically, the security manager used in Java WebStart does not necessarily reject any request for privileged behavior. Rather, it can be configured easily by either the system administrator or the user to allow such behavior when it is deemed appropriate.