[2620] in java-interest
RE: typesafe socket communication
daemon@ATHENA.MIT.EDU (Zachary Simpson)
Fri Oct 6 14:52:34 1995
From: Zachary Simpson <zsimpson@eden.com>
Cc: "java-interest@java.Eng.Sun.COM" <java-interest@java.Eng.Sun.COM>
Date: Sun, 8 Jan 1995 09:48:20 -0600
I must still be missing something. By "security risk" do you mean virus =
protection or class security? I presume you mean both. I can imagine a =
scenario where there was a class that had a private member which was =
some int handle to an important data structure, and that if you were =
able to modify this private handle you could corrupt this data =
structure. However, at some point it has to come down to one of two =
things: either 1)some java code in a library is being interpreted by the =
runtime system which would apply a final sanity check to the addressing =
or 2) some native code which should be doing bounds checking on all of =
its memory accesses.
Remember, we're suggesting that must declare an object as persistifiable =
and thus you can do two levels of checking:
1. During compie you can ensure that the persistifiable object does not =
contain any pointers (non-atomic types) and (if you wish) no private =
data members.
2. At runtime you can double check the length of the bytes[] being =
loaded against the length of the type being cast to.
We are not suggesting a more general solution which would open up these =
problems. It would be very useful to have even this limited solution as =
pointed out in yesterday's example of stream input.
I really don't see the problem, please enlighten further.
Thanks
Zack Simpson
Titanic Entertainment
zsimpson@eden.com
________________________________________________________________________
Seems to me that you can make either of these safe by moving all of =
the typecasting code into the runtime module and doing extensive =
typechecking. Following the guidelines we suggested yesterday, this =
should be perfectly safe as long as you store all the necessary type =
information at runtime. I must be=20
----------
From: Arthur van Hoff[SMTP:Arthur.Vanhoff@Eng.Sun.COM]
Sent: Thursday, October 05, 1995 5:45 PM
To: zsimpson@eden.com
Cc: java-interest@java.Eng.Sun.COM
Subject: Re: typesafe socket communication
Hi,
> In a previous message, Arthur said that remote persistent objects were =
not=20
implementable because of a hornet's nest of security problems. We think =
that we=20
understand these security problems, but we're not sure. We're guessing =
that you=20
mean that arbitray type casts from byte[] to some class will mean that =
it is=20
possible to "lie" to the runtime system and convince it that you're =
handing it=20
one structure when in fact you're handing it something else. However, =
this is=20
only a security problem if any of the destination fields of the class =
are=20
considered pointers (i.e. not atomic data types like int, etc.) Even if =
the=20
data stream did get typecast into a class which contained an object =
pointer,=20
these object pointers could be double checked against the heap address =
space=20
during the instanciation to avoid creating a pointer outside of the heap =
(i.e. a=20
potential virus).
>=20
> Thus, we clearly don't understand the problem since Arthur is saying =
that=20
there is a big security risk here. As far as we can tell, you should be =
able to=20
implement this is a totally typesafe fashion. Additionally, it seems =
like the=20
ClassLoader class already has this problem (other than the fact that we =
can't=20
figure out how to write out a class that it knows how to read back in! =
:)
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.
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.
All this can be solved using public key encryption, but that is a =
another
can of worms.
Have fun,
Arthur van Hoff
=09
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
