Java vs. .NET Security, Part 1
by Denis Piliptchouk
Security Configuration and Code Containment
This article initiates a series that will provide a side-by-side technical comparison of security features of Java v1.4.2/J2EE v1.4 (beta2) and .NET v1.1 platforms. The following areas will be considered: Security Configuration and Code Containment (this article, Part 1), Cryptography and Communication (Part 2), Code Protection and Code Access Security, or CAS, (Part 3), and Authentication and User Access Security, or UAS, (Part 4).
This series is based on the research material that was used as a foundation of the feature article, "Securing .NET and Enterprise Java: Side by Side", which was written by Vincent Dovydaitis and me, and which appeared in Numbers 3-4 of Computer Security Journal in 2002.
It would be unrealistic to expect complete and detailed coverage of all aspects of platform security in the space available. Rather, this series attempts to highlight the most important issues and directions, leaving it up to the reader to check the appropriate manuals and reference literature.
Another important aspect of platform security is that it does not attempt to deal with all possible types of threats, thus requiring the services of an OS and third-party software (such as using IIS in .NET). These services and applications will also be outside of the scope of this publication.
Configuration on both platforms is handled through XML or plain-text files, which can be modified in any text editor, or through the supplied tools. However, the platforms differ significantly in how they handle configuration hierarchies.
In the .NET world,
Caspol.exe can be used to modify all aspects of security configuration. The former provides a GUI interface, shown in Figure 1, to modify it.
Figure 1. Mscorcfg.msc screen
On the other hand,
Caspol.exe provides a number of command-line options, appropriate for use in scripts and batch routines. Here's how it would be used to add full trust to an assembly:
caspol -af MyApp.exe.
Java platform provides a single GUI-based tool,
policytool.exe, shown in Figure 2, for setting code- and Principal-based security policies. This tool works with arbitrary policy files (as long as they are in the proper format), as opposed to .NET, where names and locations of the configuration files are fixed (see below).
Figure 2. Policytool.exe screen
.NET defines machine-wide and application-specific configuration files, and allows for enterprise, machine, and user security policy configuration, whose intersection provides the effective policy for the executing user.
These file have fixed names and locations, most of them residing under the Common Library Runtime (CLR) tree, at:
%CLR install path%\Config
For .NET v1.1, the location is:
Multiple versions of CLR may co-exist on the same computer, but each particular version can have only a single installation. Since security policy files cannot be specified as runtime parameters of .NET applications, this centralized approach hurts co-existence when applications require conflicting policy settings.
Three security configuration files (enterprise, machine, and user) contain information about configured zones, trusted assemblies, permission classes, and so on. The general machine configuration file, on the other hand, contains machine-wide settings for algorithms, credentials, timeouts, and so on. Additionally, certain parameters (for instance,
ASP.NET authentication/authorization parameters) can be configured or overriden in the application configuration file. The files' names and locations are listed below:
- User security configuration file:
%userprofile%\Application data\Microsoft\CLR security config\vxx.xx\Security.config
- Machine security configuration file:
%CLR install path%\Config\Security.config
- Enterprise security configuration file:
%CLR install path%\Config\Enterprisesec.config
- Machine configuration file:
%CLR install path%\Config\machine.config
- Application configuration files:
ASP.NET) in the application or web project's main directory
Core Java and J2EE configuration files have specific locations, but locations of additional configuration files for extension and J2EE products vary by vendor. J2SE does provide significant runtime flexibility by using a number of command-line application parameters, which allow the caller, on a per-application basis, to set keyfiles, trust policy, and extend the security policy in effect:
java -Djava.security.manager -Djava.security.policy=Extend.policy Client1
or to completely replace it:
java -Djava.security.manager -Djava.security.policy==Replace.policy Client2
The Java platform's specifications require the following configuration files:
This file defines security properties for VM: security providers, policy providers, package access restrictions, keystore types, and so on.
Machine and user security policy that grants evidence- and Principal-based code permissions. Additional/alternative files may be specified on the command line or in the
These files contain Servlet and EJB deployment instructions and include, among other parameters, authentication/delegation settings, security roles, role-based Access Control Lists (ACL), and transport security configuration. The "UAS" section in Part 4 of this series will provide more detailed coverage of their elements.
Certain JVM parameters may be configured only in
$JAVA_HOME/lib/security/java.security, as shown in the examples below:
- Adding third-party providers:
- Configuring alternative policy providers:
- Specifying multiple policy files:
Note: By allowing command-line JVM parameters, Java provides a significantly more flexible and configurable environment, without conflicts among multiple JVM installations.
Pages: 1, 2