This is an HTML rendering of a working paper draft that led to a publication. The publication should always be cited in preference to this draft using the following reference:
Department of Informatics, Technological Educational Institute (T.E.I.) of Athens
Ag.Spiridonos St., Aegaleo, GR-12243, GREECE
Tel: +30-1-5910.974, Fax: +30-1-5910.975, Email: firstname.lastname@example.org
Department of Information & Communication Systems, University of the Aegean
Research Unit, 30 Voulgaroktonou St., Athens GR-11472, GREECE
Tel: +30-1-6456.688, Fax: +30-1-6448.428, Email:
Department of Informatics, Athens University of Economics and Business (AUEB)
76 Patission St., Athens GR-10434, GREECE
Department of Information & Communication Systems, University of the Aegean
Research Unit, 30 Voulgaroktonou St., Athens GR-11472, GREECE
Tel: +30-1-6456.688, Fax: +30-1-6448.428, Email:
is a system programming language having a number of advantages
over traditional programming languages, due to the fact that it
is a platform - independent language, thus promising truly network
oriented computing as well as a nearly universal system for distributing
applications. On the other hand, although being an interpreted,
much simpler, scripting language, Safe-Tcl was proposed as an
executable contents type of MIME and thus as the standard language
for executable contents within email. Consequently, both languages
claim to be suitable for transmitting executable content over
the Internet, in other words providing mobile code. However, the
ability to download, integrate, and execute code from a remote
computer raises serious concerns about Java's as well as Safe-Tcl's
effect on network security. In this paper, the details of each
of the proposed security mechanisms are presented, as well as
a comparison of the two security models, centered upon the efficiency
and flexibility of current implementations as well as upcoming
Java is a general-purpose class-based object-oriented language that has been developed and distributed by Sun Microsystems. Since its first release in February 1996 it has been experiencing a continuously growing interest due to an important capability provided by the Java platform, and not found in traditional programming languages. This ability allows Java programs written on one type of hardware or operating system to run unmodified on almost any other type of computer. However, security concern becomes especially important in such an environment, since the presence of downloaded executable content makes the local computer vulnerable to a potential attack from the possibly untrusted source of the executable. In recent versions, Java promises that through its new security mechanism it provides a secure environment for downloadable executable content that under specific circumstances can make use of a system's resources without compromising their availability and integrity [McGraw, 1996].
Safe-Tcl, a special purpose language, is based on Tcl, a procedural, high-level, scripting language designed to be simple, portable, easily embeddable and extensible. Safe-Tcl makes it possible for people to execute programs written in the Tcl language without knowing their origin or trustworthiness. It deals with potential security problems by restricting the behaviour of programs so that they have fewer capabilities than the users who invoked them. According to Tcl's designer J. Ousterhout, the proposed Safe-Tcl security model has two particular strengths: it separates untrusted code from trusted, with clear and simple boundaries between environments having different security properties, and provides mechanisms for implementing a variety of security policies.
Hostile applets are Web-embedded Java programs that may perform hostile activities against Web users, or Tcl scripts delivered via the context of email that manage to harm the destination hosting machine or application, while being executed there.
This paper addresses the security problems associated with Java
and Safe-Tcl programming languages and provides some solutions
for them. Section 2 provides a brief overview of the Java programming
language focused particularly on the manner Java addresses downloadable
executable content security issues. Section 3 on the other hand,
describes the basic mechanisms of the Safe-Tcl security model.
Current implementations as well as upcoming extensions of the
two security models are compared in section 4, where their efficiency
and flexibility are evaluated. Finally, in section 5 general remarks
are discussed and in section 6 conclusions are presented.
2. JAVA LANGUAGE AND SECURITY
One of the major design goals of Java is portability, which means that it is architecture neutral and consequently platform independent. More precisely, a Java program is portable not only in source code but also in compiled binary code. This is achieved through Java Virtual Machine (JVM), a system that simulates an imaginary virtual machine [Sun, 1997a], [Sun, 1997b].
Java's security model is focused on protecting users from hostile applets downloaded from untrusted sources across a network [Venners, 1997]. To accomplish this goal, Java provides a customisable sandbox in which Java programs run. Within its sandbox, the applet may do anything it wants but cannot gain access to the user's files, network connections or other resources.
Applets are loaded from the network by the applet ClassLoader which receives the bytecode instruction stream and converts it into internal data structures that represent the applet's classes. It then creates a namespace where it places the symbols of all the applet's classes. The Class Loader invokes the Bytecode Verifier before running a newly imported applet. The verifier subjects each applet class to a number of tests to prove that the applet will not be allowed to corrupt part of the security mechanism or to replace part of the system with its own code. The Security Manager is an abstract class that enforces the boundaries around the sandbox. Whenever an applet tries to perform an action which could corrupt the local machine or access information, the JVM first asks the security manager if this action can safely be performed.
The JDK is the official Java implementation from Sun. JDK1.2 includes a set of new features [Gong, 1997a], which introduce another modus operandi for the Java security system. The security policy introduced by JDK1.2 comprises of a mapping between properties of the running code (the URL of the code and the code signature) and a set of permissions granted to that code. If a piece of code carries more than one signatures then the permissions it is entitled to are computed as the sum of permission each signature is entitled to.
Permissions may no longer be granted in JDK1.2 to classes but to protection domains. The latter consist of all the objects that correspond to a principal who has been authorised by the system. Every class may belong to one domain only. It is possible to prevent the communication between different domains. When such a communication is necessary it may be performed either indirectly through system code, or directly if all the participating domains allow it.
Until JDK1.1, the code that performed access controls had to know the status of all its callers; these checks had to be performed by the programmer. JDK1.2 introduces a new class called AccessController which simplifies this process. A programmer may call the checkPermisssion method of this class, thus having the system itself perform the access control on behalf of the programmer.
The ClassLoader class has been replaced by the SecureClassloader. The latter can distinguish system classes from others and impose the designed security policy. In order to impose the security policy to locally installed applications, a new class has been introduced, called java.security.Main.
JDK1.2 and most of the emerging Java security frameworks applications
depend on the existence of a Public Key Infrastructure (PKI).
It is an obvious necessity for these frameworks to support the
widely accepted standards for PKI and for the security mechanisms
that surround them, such as X.509v3 certificates, SSL, and HTTPS.
3. THE SAFE-TCL LANGUAGE AND
Safe-Tcl was developed by M. T. Rose and N. Borenstein. It is based on J. Ousterhout's Tool Command Language (Tcl), which is a high-level interpreted scripting language.
The syntax of Safe-Tcl is identical to the syntax of Tcl [Borenstein, 1993]. Safe-Tcl is in fact an extended subset of Tcl, in that the "dangerous" primitives in Tcl have been removed, while certain new primitives presumed safe under all security policies have been added.
Like Java, this language is also safe with respect to memory usage (no C-style pointers, enforced bound checking in array references, storage managed automatically by Tcl interpreter). An interpreter consists of a set of Tcl commands, a set of variable values, and an execution stack, thus encapsulating completely the execution of a Tcl script. The facilities available to a Tcl script are determined by the set of commands defined in its interpreter.
Safe-Tcl also addresses security by controlling the execution of Tcl scripts by using a padded cell approach. According to this approach, applets (that is Tcl scripts, often called tclets) are executed in an isolated environment where their capabilities can be restricted in order to conform with the applied security properties. The isolation is achieved by using the dual-interpreter mechanism [Ousterhout, 1996].
According to this, two Tcl interpreters must be running at the local site in case of an application that wishes to execute an applet: the trusted interpreter and the unstrusted interpreter (the designations "Trusted" and "Untrusted" refer to the origin of the code being interpreted, rather than the interpreters themselves). Only trusted scripts such as those written by the user or the application may execute in the trusted interpreter, which retains full functionality. The untrusted interpreter is used for executing the applet, so all the commands that could result in endangering the system's security are made inaccessible.
The primary mechanism used by Safe-Tcl to provide restricted access to features that are essentially unsafe is command aliases. An alias is the association between a command in the untrusted interpreter and another command in a fully-trusted interpreter. Whenever the former command is invoked by a script in the untrusted interpreter, the latter is the one that is actually executed instead. To be more precise, the Tcl procedure that corresponds to the command in the trusted interpreter receives all the arguments from the command in the untrusted interpreter and, after being executed, its result is returned to the trusted interpreter as the result of the local command.
As mentioned before, all the commands that could result in endangering the system's security are made inaccessible to the untrusted interpreter. However, these commands are just hidden in some way, so as to make it impossible for the untrusted interpreter to invoke them. Having the capability to manage the entire set of those commands, the trusted interpreter may also invoke at any time the hidden commands of the untrusted interpreter. Doing so, it is able to use those commands in a restricted way, since they are invoked in the context of the untrusted interpreter and that is the place where their side effects will occur.
From the above description of the mechanisms used in Safe-Tcl
stems one of the most important strengths of the security model
that is proposed: Safe-Tcl does not prescribe any particular security
policy, but rather provides mechanisms for implementing a variety
of security policies. Since a security policy consists of
the commands available in safe interpreters using the policy,
it is possible to implement highly restrictive security policies
for scripts of unknown origin, by providing no aliases at all
in their interpreters.
4. EXTENSIONS AND
The JDK 1.1 includes a Java core API, built out of the java.security package that allows for digital signatures and message digests, key management, certificate management and access control. The Java Cryptography Architecture refers to the framework for accessing and developing cryptographic functionality for the Java platform and encompasses nearly the entire Java security API.
A concrete implementation of the Java security API is referred as a Cryptography Package Provider. JDK 1.1 comes with a default provider named SUN which includes an implementation of the NIST DSA algorithm, the MD5 and SHA message digest algorithms [Schneier, 1996]. JDK 1.1 provides a security tool, the javakey, whose primary use is to generate digital signatures for archive files (JAR files) which enable the packaging of class files. To sign an applet the producer first creates a JAR file and then creates a digital signature based on the contents of the JAR.
Since the ability to encrypt the data prior to being transferred is very important, APIs for data encryption are contained in a Java Cryptography Extension, as an add-on package to JDK.
Recently, new policy enforcement methods, secure code distribution
and Java firewall blocking methods have been found and some of
them implemented. These are briefly presented in the following
4.1.1 Policy enforcement methods
Once the code is authenticated to the system, that is associated with a principal, it is subject to the policy defined for that principal. To enforce this policy, three secure methods have been proposed [Wallach, 1997]:
Fundamentally, a capability is an unforgeable pointer to a controlled system resource. To use a capability, a program must have been first explicitly given that capability, either as part of its initialisation or as the result of calling another capability. Every top level class of an applet can be given by the system an array of capabilities (pointers to objects). Then the applet is able to use these capabilities whenever it wishes. The objects that are referenced by the capabilities may implement and enforce their own, internal security policy, by checking the parameters with which they are called. The Java runtime would have to be modified in order to make private all the methods which handle system resources directly or indirectly. It is only the capabilities themselves (the referenced objects) that should have access to these methods.
Capabilities are easy to implement in Java, because of the underlying
infrastructure. Systems that support "capabilities"
have been researched. One of these is the Java Electronic Commerce
Framework [Goldstein, 1996], which provides a security platform,
complementary to the one that Java is using right now, which is
able to implement complex trust relationships between entities.
Extended stack introspection
The extended stack introspection is based on three primitives that must be implemented:
Every system resource must be associated with a target. Before
the system allows the use of a system resource, it should perform
a checkPrivilege on the specified target. When a thread,
associated with a principal, asks for a system resource it should
perform an enablePrivilege on the specified target. The
security policy will then decide whether that principal is entitled
to use this target and the system will or will not grant the privilege
to the code. After the thread has finished using this system resource
it must execute a disablePrivilege. The checkPrivilege
primitive should check the stack and judge whether a privilege
must be given or not based on the least privilege rule,
in order to prevent trusted code from calling untrusted code and
passing the latter the privileges of the former.
Name space management
Name space management is a method to enforce a security policy
by replacing or hiding the classes that are visible by a program.
There has to be a mapping between the applets (and their respective
signers) and the namespaces that each applet will be able to see.
Hiding a class from the namespace means that the applet may not
be able at all to use it, while replacing the class with another
(possibly a subclass of the latter) provides a means for controlling
even more the way that the applet will call and use the methods
contained in the aforementioned class.
4.1.2 Secure Code Distribution
Secure code distribution [Zhang, 1997] is one of the security
issues that concern the Java community. There are various approaches
to authentication for secure code distribution. One of them is
the signed applets. The Java class file format is extensible.
It is possible to add new attributes to it, without influencing
the current structure or workflow of the classloaders. These new
attributes can contain signatures for the applet which can be
verified, provided that the user possesses the certificate of
the entity who signed the applet. After the verification the security
manager may grant certain rights to the applet, depending on the
trustworthiness of the author or the person who has signed the
applet. The level of trust, and therefore the level and types
of rights that should be granted to the applet, that each user
specifies for each applet author or signer can be defined a priori
by forming a local security policy, accessible from the user through
the browser and protected by all means available (e.g. filesystem
rights) to the OS. Secure code distribution is already supported
by Javasoft's JAR specification. The signature can be verified
by the JDK infrastructure, providing a secure authentication means
for the distribution of applets.
4.1.3 Confining the use of Java in a
An organisation may wish to ban all Java incoming traffic from the Internet, but wish to deploy and use Java applets internally, in its own domain. This may be achieved by blocking the Java applets at the firewall [Martin, 1997].
If one decides to implement the aforementioned strategies, s/he should take under consideration the possibility of accidentally blocking useful information, e.g. files whose first 4-byte signature is CAFEBABE but are not Java classes, or files that contain the "<applet>" string but do not call any Java applets or even blocking files that end in ".class" but do not consist of Java classes.
The Princeton Group has released a product called JavaFilter
[Balfanz, 1997] which may be used in a complementary way, when
trying to block all Java traffic from specific hosts. JavaFilter
is available for Microsoft Internet Explorer and Netscape Navigator
for Windows and replaces the browser's classloader with a modified
version of theirs. This tool provides the ability to the end-user
to accept or deny the execution of applets from specific URL.
In the case of a trusted code source, a classloader is initialised
and loads the applet, while in the case of an untrusted one no
classloader is initialised, preventing thus even the loading of
the "untrusted source" applets. If an applet attempts
to download itself from a URL not specified as a trusted or untrusted,
then the JavaFilter asks the user whether s/he wishes to accept
this code source as a trusted one. This user acceptance may be
stored in the JavaFilter database; the JavaFilter performs automatic
lookups to that database each time an applet attempts to download
itself to the user's browser.
Safe-Tcl has been available in the Tcl releases since the Tcl 7.5 release in April 1996. Safe-Tcl integration with Tk (a window system toolkit for building graphical user interfaces) is implemented as part of a Tcl/Tk plugin module for Netscape Navigator, which was released in July 1996. The plugin allows Web pages to contain Tcl/Tk scripts, and uses the Safe-Tcl mechanism to ensure that even untrusted scripts can be safely executed. Safe-Tcl supports safe interpreters and aliases but allows only a single security policy consisting entirely of builtin commands.
Future releases are intended to include standard authentication
and encryption mechanisms to provide more control over the execution
of scripts, as well as mechanisms to prevent denial-of-service
attacks. These plans are described in the following paragraphs.
If the source of an applet is unknown, the receiving application must assume the worst and restrict actions that the applet may take. However, if the application can deduce something about the author of an applet, then it may be able to grant more privileges to the applet. In other words, if the application can determine that an applet is one of the approved ones, it can make additional security policies available to the applet. There exist a variety of authentication mechanisms for verifying the origin of a mobile code segment, most of which involve encryption of some sort.
Authentication mechanisms can be used to distribute new security
policies. For example, an untrusted applet may carry an encrypted
trusted security policy with it, so that when an application executes
the applet, it can safely load the security policy even though
it doesn't trust the applet. In that way, authentication makes
it possible for a variety of applets and applications to take
advantage of new policies developed and distributed by experts.
4.2.2 Denial-of-service attacks
Safe-Tcl mechanisms can also be used to prevent denial-of-service attacks. More precisely, aliases can be created and used instead of commands that are associated with system resources and particularly with graphical user interfaces. The basic idea is to handle many such attacks, with a kill key that the user can press at any time to destroy the applet. With this approach an application need not worry about many denial-of-service attacks, since as soon as they occur the user will notice and kill the offending applet.
However, in order to prevent denial-of-service attacks in non-interactive
applications, where the user is not able to notice the attack,
a familiar operating-systems mechanism has been proposed: mechanisms
to monitor CPU usage in Safe-Tcl will be implemented. Safe-Tcl's
approach to CPU controls is to invoke a scheduling function in
the trusted interpreter once the untrusted interpreter has executed
a predefined number of commands, which can abort the applet. For
interactive applets the scheduling function can check to see if
the kill key has been pressed, whereas for non-interactive applets
the scheduling function can implement an upper limit on CPU usage,
as well as on memory allocation.
Both the languages described above make it possible to create environments where applets with different levels of trustworthiness can be executed with an acceptable level of risk, and that is the reason for them appearing to have an edge over other programming languages for mobile code, in terms of security.
One may claim that as far as security is concerned, Java work has concentrated on providing low-level security in a preferment manner, as opposed to Safe-Tcl which has focused on the higher-level aspects of security, but only in the specialised context of email. Moreover, it is claimed by those who vote for Java that the security model it offers is more complete than the one proposed by Safe-Tcl, since mechanisms like namespace protection and bytecode compilation go a long way towards safety and efficiency [Weiss, 1996].
On the other hand Safe-Tcl has some advantages over Java that
simplify the creation of safe environments. The first is simplicity
of the proposed model. It may be considered as just a generalisation
of the user- space / kernel-space model that has been used
successfully in operating systems for several decades [Gritzalis,
1991]. The second is that data and code are grouped together with
similar security properties, which reduces the amount of code
that must be aware of security issues. Finally, security policies
are separated into well-defined modules that do not depend neither
on host applications nor on untrusted applets, making it easier
to analyse the properties of a security policy, and to reuse policies.
Currently the Sunscript group is working on Tcl-Java integration,
since Tcl has several properties that complement Java nicely.
Two new products were recently released named Jacl and
Tcl Blend [Sun, 1997c]. The first is a new Java implementation
of Tcl 8.0, that can be used to write extensions for Tcl in Java
code that will provide cross-platform portability across UNIX,
Windows and the Macintosh. The second is a new package for Tcl
8.0 that allows loading and interacting with the Java virtual
machine. This kind of integration will probably guide to a security
integration, since both languages have a built-in security
model, the combination of which may be used to have more complete
and flexible control over mobile code.
[Balfanz, 1997] D.Balfanz, E.W.Felten, (1997) A JavaFilter, online http://www.princeton.cs.edu/sip
[Borenstein, 1993] Borenstein N, Rose M.T., (1993) MIME Extensions for Mail-Enabled Applications: application/Safe-Tcl and multipart/enabled-mail
[Goldstein, 1996] Goldstein T., (1996) The Gateway Security Model in the Java Electronic Commerce Framework, JavaSoft, online http://www.javasoft.com/products/commerce/jectf_gateway.ps
[Gong, 1997a] L.Gong, M.Mueller, H. Prafullchandra, R.Schemers, (1997) Going Beyond the Sandbox: An Overview of the New Security Architecture in the Java Development Kit 1.2, Proceedings of the USENIX Symposium on Internet Technologies.
[Gritzalis, 1991] Gritzalis D., (1991) Information Systems Security, GCS Publications (in Greek).
[Martin, 1997] Martin D., Rajagopalan S., Rubin A., (1997) Blocking Java Applets at the Firewall, Proceedings of the SNDSS 1997 Symposium on Network and Distributed System Security, pp.123-133, IEEE Computer Society Press.
[McGraw, 1996] McGraw G., Felten E., (1996) Java Security Hostile Applets, Holes and Antidotes, J. Wiley & Sons Inc.
[Ousterhout, 1996] Ousterhout J.K., (1996) The Safe-Tcl Security Model.
[Schneier, 1996] Schneier B., Applied Cryptography, J.Wiley & Sons.
[Sun, 1997a] Sun Microsystems, (1997) Secure Computing with Java: Now and the Future, at http://java.sun.com/marketing/collateral/
[Sun, 1997b] The Java Virtual Machine Specification, (1997) online http://java.sun.com/docs/books/vmspec/
[Sun, 1997c] Jacl and Tcl Blend, (1997) online http://sunscript.sun.com/java/
[Venners, 1997] Venners B., (1997) Java's security architecture, online http://www.javaworld.com/javaworld/jw-08-1997/jw-08-hood.html
[Wallach, 1997] D.S.Wallach, D.Balfanz, D.Dean, E.W.Felten, (1997) Extensible Security Architectures for Java, Proceedings of the 16th Symposium on Operating Systems Principles.
[Weiss, 1996] Weiss M., Johnson A., Kiniry J., (1996) Security Features of Java and HotJava.
[Yellin, 1995] Yellin F., (1995) Low Level Security in Java, online http: //java.sun.com/sfaq/verifier.html
[Zhang, 1997] X.N.Zhang, Secure Code Distribution,
(1997) IEEE Computer, June 1997, pp.76-79.