Background for talk at security and languages workshop
Dec SRC, Palo Alto, October 30-31, 1997.

*****************************************************************

1.  Gaining security by restricting the user's programming language was
explored in the 1970's and found wanting because

  a.  The TCB is too large.
  b.  The security policy model is unclear

In more detail:

In the 1960's and early 1970's several people suggested that limiting the
user to a single, carefully controlled, interpreted or compiled language
was a way of achieving security.  Later in the 1970's, this idea was
discarded, as the concept of a Trusted Computing Base became clear, because
it it was realized that the TCB needed for a controlled language was so
large that one had little hope of assuring its correctness and integrity.

Ex.

Paul L. Peck.  Survey of Applicable Safeguards for insuring the integrity
of information in the data processing environment.  Mitre Technical Report
MTP 356, June 1971, page 11:

"Restricting Users to Programming in Higher-Level Languages.  Programs
written in higher-leel languages are either executed in the interpreter
mode or translated and assembled by a compiler, then executed, consequently
additional security is provided since the user is isolated from the system
by the source program translator."

Ex.

Anderson, J. P. Computer Security Technology Planning Study, ESD-TR-73-51,
vol. II, ESD/AFSC, Hanscom AFB, Bedford, Mass., October 1972, pages 36-37:

"A higher order language-only system is one in which the user of the system
can program only in one or more approved languages that are translated ...
by an approved compiler, and which are executed in an approved environment.

We establish the following requirements for a secure higher order language
(only) system.
   a.  There is a rigorous separation of code from data...
   b.  All references to data are validated...no code locations are
       accidentally or otherwise obtained
   c.  all transfer of control are validated...only to recognized labels.
   d.  all i/o transfers are validated..."

http://www.disa.mil/MLS/info/orange/
The orange book.

Glossary:  Trusted Computing Base (TCB) - The totality of protection
mechanisms within a computer system -- including hardware, firmware, and
software -- the combination of which is responsible for enforcing a
security policy.

6.4  ... the TCB must be of sufficiently simple organization and complexity
to be subjected to analysis and tests, the completeness of which can be
assured."

Anderson, J. P. Computer Security Technology Planning Study, ESD-TR-73-51,
vol. I, ESD/AFSC, Hanscom AFB, Bedford, Mass., October 1972 (NTIS AD-758
206), pages 9-10:

"c. The reference validation mechanism must be small enough to be subject to
analysis and tests, the completeness of which can be assured."

Ibid., page 22:  "GCOS's sheer size (300,000 instructions) prevents
analysis and testing."

Let's look at the Java sandbox--exactly what do we need to trust? (N. B. 
The following analysis is based entirely on James Gosling and Henry
McGilton, The Java Language Environment: A White Paper, Sun Microsystems,
Inc., October,
1995, so it may be incomplete or incorrect.)

  - bytecode verifier:  it must correctly verify the byte code

  - bytecode loader:  it must correctly load and link things

  - bytecode interpreter:  it must correctly implement the restrictions

  - java io package:  no security-related bugs

  - java. garbage collector, memory allocator, and  thread
    package:  no security-related bugs 

  - java window package:  no security-related bugs

  - supply lines:  do we have an authentic copy of the verifier,
    interpreter, loader, and java runtime

  - safe language design:  The particular choice of language
    functions must actually be safe.

  - IEEE 754/854 (floating point) specification:  does it 
    introduce any concerns?

  - Bytecodes:  Is it possible to comprehensively verify things 
    written in this language?

  - Separate Name Spaces for each network source:  Must be able to
    securely identify distinct sources.

  - Separate Name Space for sources from local file system:  Must 
    trust all locally-stored sources to be friendly.  (Is there any 
    way for a Java applet to download a distant file into the local 
    file system?  How about by invoking a mail receiver?)

  - Class name search:  first local, then referencing name space.  
    Must verify all possible results of searches through unknown 
    name spaces.

  - "network access to only hosts from which code was imported"  Must
    securely identify source host (depends on DNS) and securely
    reconnect (depends on DNS (originally), IP layer, and integrity 
    of network)
  
  - "network access [] outside the firewall [only] if code came from
    outside."  Must securely distinguish between inside and outside code.
    Must securely distinguish between targets inside and outside the
    firewall.
    

We have here two basic problems: lack of an understandable security model
and a too-large trusted computer base.

The TCB (trusted computer base--the stuff that must work right for the
security perimeter to be properly defended) is too large and complex to
ever be correctly implemented or to pass any credible assurance test.  For
such a large TCB, the rate of introduction of new bugs will probably always
exceed the rate of removal of old ones.  The TCB is so large that it is
hard to figure out just how large it is.  For example, until someone (the
guys at Princeton?) pointed it out last spring, DNS was accidentally
included in the TCB.  (And Sun even tried to defend that inclusion, for a
short time.)

Back in the 1970's the size of the TCB was one reason identified by
security specialists for not going in the direction of what would today be
called an interpretive sandbox.  I can't find anything that has changed. 
The list of Java implementation problems that have been uncovered suggests
that the 1970's assessment was a good one.

Question:  What has changed to make the 1997 assessment different?
    
*************************************************************************

2.  The psychology surrounding sandbox design guarantees that it will never
work in practice.

The holes reported in Java security aren't fundamental flaws, but they are
there because Java's security model is fundamentally flawed.  The problem
is in part psychological and in part political.

The best way to build a completely safe sandbox is to allow the applet no
access to any resources and functions of your computer.  Unfortunately, the
applet then won't be able to do anything interesting.

In Science 273,5275 (2 August 1996) on page 592 there is a quote by
Marianne Mueller of JavaSoft:  "There is a tension between being secure and
doing interesting things."

So you try to drill a limited set of holes in the sandbox and let the
applet do a few things with the network and local resources such as the
file system.

Now, which holes are safe to drill?  Noone has worked out a believable
model for what functions can be safely provided.  Some functions are
probably safe, some are obviously unsafe.  For most functions, the question
isn't answerable.

Noone knows of any systematic way to look at a proposed set of interactions
with the environment and say, "this set of interactions can be made safe"
or, "this set of interactions can't be made safe".   There may be some sets
where that determination is possible, but for many interesting sets and our
present understanding, the answer is almost certainly, "can't tell."

Giving the applet the ability to draw on the display, but only inside a
window that is bordered in red and titled "Don't believe anything you read
here!" may be safe.  Giving the applet the ability to reformat the hard
disk is probably not safe.  Now, make a (conceptual) list of all the
functions that anyone might propose allowing the applet to do, and try to
categorize them as "safe" or "unsafe".  You can identify a small number as
probably safe, and several more as probably unsafe.  But you are certain to
be left with a whole bunch of functions for which you can't say with any
confidence whether it is safe or not.

Even with all the understanding of security that has developed over the
last thirty years, there will always be this residual set of "not sure
about this one".  The residual set may be large, and more important, it is
guaranteed to include a number of "interesting" functions that would be
very useful to have available.

Watching the hype surrounding Java, I don't have any reason to believe that
its designers are likely to insist on staying on the conservative side of
that boundary.

To see why, put yourself in the shoes of a designer of a Java-style system:
 You must choose the function set you are going to make available.  
Naturally you take everything that you are confident is in the safe set. 
And you will exclude everything in the known-unsafe set.  But what about
the stuff in the unknown set?  Since more interesting applications will
require a longer list of interactions, there will be pressures to move in
the direction of more interactions, and cross the boundary between "this is
safe" and "can't tell".  There is sure to be some very useful function in
the "can't tell" set, and there is also sure to be someone with a
persuasive argument along the following lines:  function Z is safe because
1) he believes he has designed a way of doing it in safety, 2) it is very
useful, and 3) noone has demonstrated that it isn't safe.  Because it is
useful, marketing will insist that function Z be made available.

If you try to limit yourself to the guaranteed safe set, your detractors
will declare your language worthless and go on to create a competitor that
is more "interesting" than yours.  Since most prospective customers aren't
sufficiently security-aware to understand what is safe and what isn't, they
will adopt the language that can do more, and write off the negative
comments from the security experts as coming from a bunch of paranoids. 
The temptation to include functions from the unknown set is thus
overwhelming.  And the next thing you know, the guys at Princeton have
demonstrated that function Z, in combination with functions Y and X (both
of which were argued to be safe in isolation) is hazardous to everyone's
health.

You can see the dynamics of this phenomenon going on today with Java.  The
language designers included some functions from the "can't tell" set, and
they are now madly patching to try to secure them.  Here is where
experience can help:  Over the last 30 years a lot of effort has been
wasted trying to secure  systems that weren't originally designed to be
secure.

This is actually a problem in design and marketing psychology, but in the
security area, that is fundamental.  The psychological pressure on the
creators of Java to declare that some of the unanswerable things are safe
is so great that we can expect an endless list of problems like the ones
already found.

Unfortunately, establishing whether or not an implementation is right is a
little like debugging perpetual motion machines.  As fast as someone at
Princeton finds a bug, the people at Sun patch around it and declare it
safe again.

Let's return to the size of the TCB.  Even if someone did hand me a magic
procedure that could analyze a particular set of interactions with the
environment and declare that it can in principle be made safe, It seems
likely to me that the mechanism to sandbox must increase rapidly in
complexity as the list of environment interactions grows.  Thus the
above-mentioned pressures to add interactions to the list, even if someone
can establish in principle that they don't cross the safety boundary, have
the effect of making implementation certification much harder.  This
strikes me as another scary element in the Java game plan.

Final caveat:  It may well be that sandboxes could play a role in helping
people who are concerned about reducing that last increment of risk,
because sandboxes can be fairly good at corralling non-malicious
destructive behavior.  My concern with that approach is that sandboxes may
also create a crutch of dependence:  people may come to rely on them to
also prevent malicious behavior, which I believe is an unrealistic
expectation.


---------------------------
re:  code signing as an alternative
---------------------------

Code signing has two flaws, too, so it doesn't solve the problem either. 
But it is going to be part of the scene and maybe someday someone will come
up with a combination of sandboxes and code signing that actually provides
some measure of safety.


> ...For these programs 
>the only way is signing, which can give you as good assurance as you 
>get from a box at Egghead.

I think there is another subtlety that distinguishes signed applets from
shrink-wrapped boxes from Egghead.  Occasionally I click on a link and my
browser reports that the thing I am trying to grab is of a type I'm not
prepared to handle.  When that happens, I stop to ponder about whether or
not I want to take on the acquisition, installation, maintenance, and risks
of yet another Netscape helper.  In making the decision I may refer to a
review of the program in MacWeek and my experience with the organization
that wrote it, or I may ask someone down the hall about their experience
with it.  The current Java downloading model, even if implemented with
signed applets, seems to encourage cutting me out of that decision process.

************************************************************************

3.  Where is the easily defensible boundary?

In RISKS forum digest 17:93, distributed Sunday, March 24, 1996, the group
at Princeton reports another Java security problem.  This one allows an
applet to execute arbitrary machine language code on the client. Ominously,
they are declining to reveal details, pending fixes from NetScape and Sun.
Meanwhile, the recommendation is to disable Java, even if you have the
latest 2.01 browser, which allegedly fixes all previously reported security
problems.

It seems to me that one of the basic things going wrong here has to do with
where one chooses a line to do battle.  One does better to choose lines
that are easily defended.

The client/server model, because it places the client and server at arms
length and restricts their interaction to messages (which can be audited,)
provides an opportunity for an easy-to-understand and easy-to-defend
security boundary:  Everything inside your computer is trusted, everything
outside is untrusted.  With this view it is necessary to check carefully
anything that comes in across the boundary, but once checked it isn't
necessary to maintain security firewalls inside the machine.  It is still a
good idea to maintain fault isolation firewalls within a computer, but
those firewalls aren't required to be foolproof under malicious attack.

This perspective simplifies private workstation design and operation, as
compared with a time-sharing system.  The time-sharing system must maintain
leakproof security boundaries between multiple users running arbitrary
programs inside a single computer.  Implementers of systems like the
Macintosh (and perhaps Windows) have taken advantage of the reduced
requirement for leakproof internal security to simplify their designs.
Downloading of code in these systems is usually done with FTP-like
protocols, which give the user an opportunity to think about where the code
is coming from and perhaps run a virus-checker before executing it.  These
measures don't guarantee the absence of malicious programs, but they do
discourage attackers from trying this route.

And users of private workstations that run UNIX, even though the operating
system offers better security firewalls, are usually much more relaxed in
their operation and management of the security features, because they are
instead depending on the network boundary as the real security boundary. As
an example, the Athena system does not attempt to maintain privacy of the
root password for its public workstations.  Instead, internal boundaries
are assumed to be breachable and are maintained primarily for fault
isolation.  But it does have a very strong authentication system for
checking on the source of packets coming in over the network, the first
step in defending that boundary.

The perspective also can simplify server design.  Although servers that act
as trusted intermediaries must maintain firewalls to keep their customers
separated, many such servers do just one thing:  run a single,
management-provided program.  That program can trust itself not to be
malicious.  A server such as a supercomputer that runs arbitrary,
user-provided code doesn't get to take advantage of this simplification.

All the opportunity for simplification also goes out the window if your
workstation accepts arbitrary packets and automatically runs them as
programs, as with Java.  The situation is too close for comfort to that of
the supercomputer.  The change moves the security firewall boundary to
somewhere inside your computer; design, implementation, operation, and
management must all adjust to a higher standard that is not well understood
by casual users.

Java moves the boundary from the network attachment back inside the
computer, thus reintroducing the ground rules of a time-sharing system.
Code that I have neither inspected nor approved can be downloaded and
executed by my workstation without notice every time I follow a link.  The
automatic verification scheme that comes with Java is intended to
ameliorate the problem by providing a first-round inspection, but with the
perspective outlined here, it is apparent that automatic inspection is just
the first step, and it isn't yet clear that even that step can be made
foolproof.

Not permitting downloading is a simple way of assuring that you don't cross
that boundary.  But once you accept the principle of downloading applets,
you then have to trust the Java designers not only to choose the set of
interactions conservatively, but also not to be tempted to add interactions
that cross the boundary in future releases of the language and browser.
This strikes me as scary.


************************************************************************

http://java.sun.com/security/UWdetails.html

http://kimera.cs.washington.edu/flaws/vacuum/
Javasoft/Sun Flaw #25: The Vacuum Bug Security Flaw in JDK
1.1 June 23, 1997

http://discuss.foresight.org/~peterson/CSFactForum.html

princeton's security page on Java
http://www.cs.princeton.edu/sip/

http://www.microsoft.com/ie/ie40/features/ie-security.htm
http://www.microsoft.com/java/security/default.htm
microsoft's view.

http://www.netscape.com/assist/security/index.html
netscape's view.