[2623] in java-interest
Re: typesafe socket communication
daemon@ATHENA.MIT.EDU (David Hopwood)
Fri Oct 6 20:41:38 1995
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
To: java-interest@java.sun.com
Date: Fri, 6 Oct 1995 23:14:49 +0000 (BST)
Reply-To: java-interest@java.sun.com
In-Reply-To: <199510052345.QAA14940@jakarta.Eng.Sun.COM> from "Arthur van Hoff" at Oct 5, 95 04:45:48 pm
>
> > In a previous message, Arthur said that remote persistent objects were not
> > implementable because of a hornet's nest of security problems. We think
> > that we understand these security problems, but we're not sure. We're
> > guessing that you mean that arbitrary type casts from byte[] to some class
> > will mean that it is
> > possible to "lie" to the runtime system and convince it that you're
> > handing it one structure when in fact you're handing it something else.
> > However, this is
> > only a security problem if any of the destination fields of the class are
> > considered pointers (i.e. not atomic data types like int, etc.)
> >
> > Even if the data stream did get typecast into a class which contained
> > an object pointer,
> > these object pointers could be double checked against the heap address
> > space during the instantiation to avoid creating a pointer outside of
> > the heap (i.e. a potential virus).
Just checking against the heap wouldn't be sufficient; clients could forge
references that way.
> > Thus, we clearly don't understand the problem since Arthur is saying that
> > there is a big security risk here.
> > <snip>
>
> The problem that I was talking about is that anyone can make up a stream
> of bytes that can be turned into an object. Currently we can treat object
> references as capabilities because they are unforgable. This may not be
> the case in your scheme.
An unguessable random number can be treated as a capability, for all
practical purposes.
So, one way of doing this is to maintain a table which assigns a random key
to each 'published' object. The external form of a pointer would be something
like: (server URL, local pointer, key).
If the key is long enough (say, 64 bits), you can virtually guarantee that
anyone who gets the triple right was given the reference legitimately. If
they get it wrong, then either there was a network error or they are lying.
There are some things that you need to be very careful with, for example you
need a good RNG (better than Netscape's :-), and you have to thoroughly check
the structure of the persistent data.
> Also, if I wanted to change the value of a private variable I could try
> to persistify the object, modify the data, and de-persistify it. How do
> you stop that from happening.
The de-persistified object would be a copy (the depth of the copy would
depend on how far you traversed pointers in the original object). I.e.
you would not be changing the original.
> All this can be solved using public key encryption, but that is a another
> can of worms.
I wouldn't have thought that was really necessary. Are you just referring
to authenticating the client, or something more complicated?
David Hopwood
david.hopwood@lmh.ox.ac.uk
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
