|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Java security evolution and concepts: Read the whole series!
This article, Part 2 of a series, will cover the various aspects of securely running Java code downloaded from a network. Although mobile code is not a revolutionary concept, Java and the Internet present some unique challenges to computer security. The evolution of the Java architecture and its impact on security, different security APIs and tools, and applet security will be covered in this series.
This is not intended to be a comprehensive guide to computer security, a multifaceted issue encompassing several disciplines, departments, and cultures. Investments in security technologies should be followed by investments in personnel training, strict enforcement of policies, and periodic review of the overall policy.
Although enforcement of policies during code execution is a substantial part of security, proper security starts at the very beginning, during the generation of byte code. A language's type safety, which is enforced by the compiler and checked by the runtime environment, proves critical to an overall secure environment. Many of computing's earliest security breaches stemmed from the ability to easily overflow buffers or access memory unimpeded, situations caused in part by a language's poor type safety and inadequate enforcement in the executing environment.
Java security manifests itself in the following forms: protection built into the language, building blocks for a flexible secure environment, and protection against accidental or malicious attacks to the language and platform. Simply put, Java security should ensure that the specifications for the language and virtual machine (VM) are followed.
Despite the safety checks enforced by the compiler, the VM must still be able to deal with faulty byte code, whether generated accidentally or maliciously. Below, we'll examine the enforcement of runtime checks during execution and the evolution of the runtime environment to support the design of a very flexible security policy.
As for language security inherent in the language's design, Java's design was heavily influenced by C and C++ -- particularly their weaknesses. Consequently, the Java compiler generates warnings for uninitialized variables. The language itself is strongly typed, with many unsafe constructs omitted or modified; for example, array accesses are done with index checking. Moreover, because memory deallocation in Java is the garbage collector's responsibility rather than the programmer's, Java avoids many common programming errors in C and C++ caused by faulty memory deallocation. Finally, the compiler enforces exception-catching. This discipline of catching and fixing potential errors may not have direct security implications. However, an unhandled error might lead to unpredictable behavior, which, from a security standpoint, should be avoided.