[gclist] Java manchines and when to collect.

[Mark Tillotson]

Jeremy Fitzhardinge <jeremy@zip.com.au> wrote:

| Java's sandbox approach to security is one of the less interesting
| things about it, and certainly not essential to the language.  Any Java
| implementation must allow access outside the sandbox to be at all
| useful; even code within the sandbox must get access to software on the
| outside.

I can't let that go unchallenged - the motivating constraint behind the
design of Java was to allow the bytecode format to be automatically
verified cheaply at class-load time, and to prevent dangerously
inconsistent class files from interacting to break the security model.

You may think it's not an interesting property of the language, but it
is the property that strongly shaped its design after the Oak team
gave up on C++ as fundamentally unfixable for their purposes.  You
can ignore this aspect and treat Java _with native methods_ as just
another general-purpose programming language.

Although a lot of the sandboxing technology influenced the JVM and
bytecodes directly, the knock-on effects on the language are clearly
visible:

1) absolute type-safety - no program has arbitrary undefined results
   exceptions rather than crashes.
2) Completely determined and simple consistent semantics (although not
   necessarily well documented!), so that load-time verification is
   tractable, efficient and secure.  This is why the type system is 
   very simple, for instance.
3) garbage collection an absolute requirement, memory can only be
   allocated as an object via the initialization protocol.
4) extra-linguistic features (native methods) treated as privileged
   and rejected by the verifier.  They happen to be there to support the
   "system" aspects of the JVM, ie "kernel mode", and implement
   low-level hardware specific code.  They are not part of the
   language per se.

| The type safety aspects of Java are distinct from the sandbox,

Without type-safety the sandbox is useless, without sandbox the
type-safety is broken (just load some native methods to do an
illegal cast)
To me this feels like type-safety and sandbox are intimately bound up
together.

Parts of the sandbox are implemented in Java, parts in the VM, and
parts in native code.  The point about Java is that pure Java alone
could not implement its own sandbox other than by complete emulation -
there is a hard restriction on the reflection it provides.  For the
same reason you can't implement Java's GC in pure Java.  Both of these
require level shifting (of data<=>code in one case, object<=>memory in
the other) 

In fact aren't there some interesting theoretical research issues in
designing type-systems that can be secure, and yet give a language 
the power to write its own storage-manager/GC ??   (Getting back to
the topic)

| Of course, merely having a typesafe language and a sandbox with
| constrained accesses doesn't give you security.  Java implementation
| have so far completely ignored the problem of denial of service attacks
| which are much harder to deal with.
Tackling denial of service, a less serious problem, doesn't require
any key technology, merely the ability to monitor for suspicious
over-use of resources, and to apply quotas for those resources.
Frankly I suspect it hasn't been addressed much because it's rather
dull to implement!  People would only bother using denial of service
if they can't break a system any other way, so searching for flaws in
the sandbox has been of greater important initially.

__Mark
[ markt@harlequin.co.uk | http://www.harlequin.co.uk/ | +44(0)1954 785433 ]