[4604] in java-interest

home help back first fref pref prev next nref lref last post

Re: language level support for serialization

daemon@ATHENA.MIT.EDU (Jim Graham)
Tue Jan 9 00:54:31 1996

Date: Mon, 8 Jan 1996 20:15:44 -0800
From: flar@bendenweyr.Eng.Sun.COM (Jim Graham)
To: Arthur.Vanhoff@Eng.Sun.COM, jonl@sealevelsoftware.com
Cc: java-interest@java.Eng.Sun.COM, jim.waldo@sun.com


Hi Jonathan,

> 1) are there any java objects you can create which are insecure to
>    begin with?

It's not just objects that are inherently secure, it's objects that have
state that was set up inside a secure environment.  Many objects aren't
inherently safe or unsafe, but are only classifiable depending on the
data they contain and how that data satisfies some internal-self-consistency
metric that only the object itself can specify.

> 2) if there were a dangerous object in Java called "MachineKiller" that you
>    weren't allowed to create, yes someone could create a bunch of bits that
>    created a MachineKiller object, but NO the native java method that read-in
>    (de-serialized) the stream data would NOT create such an object any more 
>    than the new operator would.

It isn't enough that the object contains a constructor that the caller
has permission to access.  You also have to consider that the object
should represent state that the caller could duplicate through calls to
appropriately accessible constructors and state-modifier methods.  You
can't verify this in a de-serialization method without solving the
halting problem.

What you could do is to have any object that wishes to be the target of
a serialization and safe de-serialization action implement some class
called "Serializable" which defines a method that the de-serialization
method can call to have that object verify its own contents and the
security thereof before you hand a pointer back to the caller.

Unfortunately you will quickly run into situations that can't be
verified by Java code alone, such as objects which strictly control
which other objects they hand a copy of some of their private internal
state to!  You can't test those kinds of things from Java and they are
very difficult to test even from native code...

				...jim
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post