Analysis

  Now that we have presented three systems, we need a set of criteria to evaluate them. This list is derived from Saltzer and Schroeder [39].

Economy of mechanism

Designs which are smaller and simpler are easier to inspect and trust.

Fail-safe defaults

By default, access should be denied unless it is explicitly granted.

Complete mediation

Every access to every object should be checked.

Least privilege

Every program should operate with the minimum set of privileges necessary to do its job. This prevents accidental mistakes becoming security problems.

Least common mechanism

Anything which is shared among different programs can be a path for communication and a potential security hole, so as little data as possible should be shared.

Accountability

The system should be able to accurately record ``who'' is responsible for using a particular privilege.

Psychological acceptability

The system should not place an undue burden on its users.

Several other practical issues arise when designing a security system for Java.

Performance

We must consider how our designs constrain system performance. Security checks which must be performed at run-time will have performance costs.

Compatibility

We must consider the number and depth of changes necessary to integrate the security system with the existing Java virtual machine and standard libraries. Some changes may be impractical.

Remote calls

If the security system can be extended cleanly to remote method invocation, that would be a benefit for building secure, distributed systems.

We will now consider each criterion in sequence.