Security in Java sandbox model

Since its introduction, Java has reserved an important role in security issues. Although with mixed results, designers have sought to provide platform security systems implemented directly in terms of language, available to developers.

In a continuous process of evolution and refinement of the JVM has become one of the most important infrastructure for stand-alone, web, mobile and more, in this article we will focus on the evolution of the security model, commonly called a sandbox, commenting on the design errors and the current status.

Prerequisites

This article is addressed to everyone, whether they are experienced Java programmers who fasts completely readers of the topic. Some considerations will be more understandable to those who already possess some experience with this language, however, the reading of this article is suitable for any reader.

The sandbox

The original model

The original model, known as the sandbox was designed to confine potentially malicious code in an isolated environment, and highly restrictive. Java since its birth, was strongly oriented to the network and this consideration led to devise an execution model in which the code was downloaded directly from the remote, exposing the client to significant security issues.

In its first implementation, shown schematically in the figure, the sandbox only roughly distinguish between local and remote code code: the first was enjoying full access to all resources "critical" system such as, for example, file systems and various devices, the remote code On the contrary, had limited access to resources, mediated by the same sandbox: applets, now largely disappeared from the web, I have been the best known example.

This model includes a set of security mechanisms at different levels. First of all, Java is type-safe, ie there is an explicit relationship between a variable and controlled and its type (integer, floating point, string, etc. ..).
Those who have programmed in languages ​​with low / mid-level such as C and C + + know how many problems can be avoided this control: the set of implicit conversions between types, such as integer or boolean void pointers to other pointers, which are characteristic of those languages ​​at the same time become the main source of programming errors, equally committed to both beginners and experts. To minimize the possibility that the developments made blunders, the designers at Sun introduced some aspects hitherto found only in niche or university level languages ​​such as, for example, automatic memory management (garbage collection) and controls at run-time access memory (pointers, array elements, etc. ...).

The second level of protection is guaranteed by the compiler and run-time, by the virtual machine. This ensures that the bytecode, the assembler of the Java VM is executed with the proper execute permissions. In particular, two key components, the SecurityManager and ClassLoader, define a local name space to avoid interference between different instances of the VM and manage the access controls to critical resources.

JDK 1.1 - code signed

The model presented is very flexible and in the first update of the JDK (version 1.1) was introduced to the concept of trusted code to allow remote applications, if accompanied by an electronic signature recognized by the client, access to system resources. The solution, outlined in the following figure, is little more than a hack of the previous architecture and therefore require a complete rewrite in the next releases.

• <<
• 1
• 2
• 3
• >>