These are some notes on the paper Extensible Security Architectures for Java by Wallach, Balfanz, Dean & Felten which describes security policies adopted for Java code in Netscape’s Communicator 4.0. In this note will refer to that paper as the paper.

See also Ka Ping Yee’s comments on this paper.

The paper provides a clear description of capabilities and indeed how standard Java mechanisms provide capability function. The authors describe why capabilities seemed inadequate to them for the tasks at hand. The paper goes on to describe the implemented functions and how they solve a variety of security problems. Perhaps the authors are unaware of some modern work with capabilities about which only a little has been published.

The main thrust of this note is to describe how the mentioned security problems and others, can be solved in a pure capability system. We will argue that a pure capability system requires far fewer fundamental changes to the java virtual machine and that correspondingly the conceptual burden on the developer is less. I think that we will conclude that the code signature checking function is very useful, type hiding may be strategic in order overcome Java’s permissive scope rules, but that the function of the security manager is misconceived and perhaps there is no need for any such function.

The paper notes correctly some of the changes necessary to the standard libraries to guard file access according to capability discipline.

Notes on the paper in order of the paper

Section 1.1 (a-factor-of-1000-difference)
The paper observes a ratio of 1000 between switching contexts with OS technology in contrast to Java method calls. In this paper the Eros people measure a round trip of 4.9 micro-seconds on a 120 MHz Pentium, sending empty messages both ways. That’s two trips into and out of privileged mode. It excludes stub code running in user mode needed to build the message. Still Java performance is dramatically better.

All of these measurements ignore the cost of sending capabilities (object references in the case of Stack Inspection). It is a significant issue but I am not sure how it effects the outcome; probably favorably for Java.

Some work occurs at the context switch with capabilities but is moved to the execution with Stack Introspection. This is significant in comparing performance. I haven’t noticed that the paper has made this mistake.

Section 3.1.1 (Java-needs-a-notion-of-principal)
This is the point where I will begin to depart. In Keykos support for modularity and support for mistrusting communicators is the same. I may trust Joe’s code to accurately invert matrices, in part because I can check the result. Yet I may not trust Joe as trusted data custodian. Perhaps two principals can solve the problem, Joe as matrix inversion code producer, and Joe as data recipient. That distinction needs to be supported by code, however. In Keykos there are more protection domains than there are programmers! I, as programmer of a b-tree algorithm do not trust me as a matrix inversion programmer and vice versa. Java’s encapsulation helps greatly here but holes remain.
Section 3.1.1 (as advertised)
I wish that there were a protocol to find such advertisements and that they were signed by the endorsers and that the advertisement included the hash of the code. (The same hash as used in the code signature.) I seldom merely trust code. I may, however, trust it do some particular thing or conform to some policy.

Actually such endorsements (advertisements) would supplant code signatures!

Section 3.4 (Third-Approach-Type-Hiding)
I think this scheme is part of the eventual solution. I would change the details but not the flavor. More later.

Appendices:

We discuss these classes of Deficiencies (as we see them) in today’s Java world.

Problems with the Java Language

We note just a few ways that Java, as currently defined, seems at odds with capability design. These are not deep features of the language. We make here some of the same points as the paper. Electric Communities has made some or all of the same observations implicitly in their design of the language E. See their The E Extensions to Java.

The Netscape Additions

Variegated Stacks
Heaps and queues of things to do
Consider queue of tasks where authority belongs in the queue >
  • Java’s package construct makes classes more accessible than dictated by good system design. Often a class must be public merely to make it available to just one call site.
  • Objects such as System.out should not be universally accessible. The paper’s “Type Hiding” seems to me to go in the right direction.

    The Netscape Additions

    Variegated Stacks
    Heaps and queues of things to do
    Consider queue of tasks where authority belongs in the queue