Gregg Wonderly wrote:
For myself, the primary consideration is whether the arguments in RPC
calls are actually "downloaded classes" vs "downloaded data". In the
simple sense, "downloaded classes" are "downloaded data".
Downloaded data is also downloaded code, because it causes something to
happen in another computer.
I've made a lot of arguments about how RPC at the most basic level, is
a single message, "invoke" with arguments of "the object", "the
method" and "the method arguments".
What some people seem to believe, is that "downloaded data" is much
safer than "downloaded code". Practically, "downloaded data" has to
be structured in a way to be consumable, and it can also be
"manipulated" to cause the "receiving agent" to misbehave while
processing the data (the world of Internet virus and worm
manifestations). The obvious thing is how much of a problem the
misbehavior actually causes.
The most simple explanation of the problem with Java/Jini, for me,
comes down to the fact that deep inside the implementation is the act
of unmarshalling the object references associated with the parameters
to the method invocation.
It is the simple fact that the "downloaded data" can "do some stuff"
without control of the "application" (the infinite loop, memory
exhaustion and other uncontrolled activities including stack overflow)
that creates the problem.
The "receiving agent" is the JVM, and while it has ample control over
the content of the "downloaded data" to "execute it correctly", that
is completely orthogonal to "correct execution" of the application
that the downloaded software is now "alive" within.
As Sim says, the trust relationship is the current "idea" of how to
make this a tractable issue to deal with. As Zoltan also suggests,
"downloaded data" can be a more politically correct solution for many
people because it feels (and actually is because of the previously
mentioned issues) safer.
Hmm brings Perl tainted variables to mind. Data is also subject to
script injection attacks etc, not many people get data parsing right either.
I think we need to break the issues up and deal with each separately,
divide and conquer.
1. Denial of Service.
* Downloaded Code Size Limits
* Infinite loop, unmarshalling thread timeout, multicore.
* Use java.lang.reflect.Proxy, local code only for untrusted,
unidentified services, or don't use them at all.
* Data transfer limits, per invocation.
* Invocation rate limits.
2. Loss of Secret's.
* Proxy code get's access to secret objects, if it gives up
it's access to network connections first (I'm working on it).
* Use Li Gong's Method Guard Pattern, if a sensitive object
escapes accidentally, insecure code can't invoke it's methods.
3. Integrity.
* MD5 is getting old, time for something stronger than httpmd.
4. Privacy
* Use encrypted communication.
5. Identity
* We sign each other's Certificates, lets create some tools to
make this easy, require the private key be on at least two
external removable USB key's, ask the user to pull the
network cable before they use their private key. Get the
user / service provider to select their USB key in an
application window, walk them through the steps for setup.
* 7 degrees of separation, everybody in the world know's each
other through someone else.
* Certificate revocation lists.
* How many degrees of separation is acceptable for trust?
* Perhaps we should use PGP and the public key repository's?
* Don't sign people's key's you don't know.
6. Trust
* If someone I know doesn't trust someone else and I don't
know them, how can I trust them either?
* Model trust on successful human trust relationships.
* Perhaps some kind of behaviour history, like Ebay's feedback
ratings, related to identity.
* Which feedback service do you trust? Feedback services get
to rate each other too. No individual entity controls it,
if you provide false information, people stop trusting you.
It's just like in nature, we can't avoid all bad events, we do what we
can to mitigate them, that's why we have children, we reproduce and we
die from old age if we're lucky.
The Jeri endpoint and invocation layer technologies still provide the
opportunity for eliminating the use of live Java objects in remote
applications. An invocation layer factory could provide the ability
to convert the entire method invocation into an XML document which is
transferred via SOAP, raw HTTP, or otherwise, for example.
I have no objections this in principle, the performance isn't good, but
it does have the potential to get through all sorts of firewall systems
based on http, it would make a good solution where something faster
doesn't work. These types of communications should be compared with
Serialization, since they are really just different methods of
recreating objects in different JVM's. The end result is the same.
The problem you describe with objects is related to default
Serialization publishing an object's internal state and it's
vulnerability to unmarshalling attacks stealing references to private state.
Well designed object's, don't have public or protected fields, since
this gives up the possibility of security checks, proper synchronization
and flexible class evolution. (There is the occasional exception, like
Service Entry's.)
Well designed serialization is difficult, but there are some good
strategies available.
It is also possible to come up with alternate Serialization mechanisms,
but the great achievement in Serialization is the reconstruction of
complex object relationships.
So yes Serialization has some warts and I'm sure if it's creators had a
second shot, there would be fewer....
We (the Jini community) have stood around and said this, but have
largely not demonstrated it publicly. We have also not thoroughly
demonstrated how the other tools in the Jini toolkit can simplify
distributed applications by building something that works in the open
and is clearly not "just another implementation of something already
done".
But let me be clear, I am talking specifically about the Jini toolkit
distribution. There are things like RIO, Seven, Paremus' work and
many other more focused examples of the use of Jini for all kinds of
real solutions. But, the community at large seems to have a hard time
documenting and endorsing these things, which makes their visibility
limited.
We need to work on a view of Jini that includes the whole range of
problem domains and solutions that exist now, and show how "downloaded
data" that is actually "downloaded code" can be a viable solution
which in the end, simplifies your application because you don't have a
whole new layer to add to provide "the other agent" that will use your
"downloaded data" to make your application work.
Not sure I follow you here, are you suggesting we use XML SOAP to
replace serialization over the net to get around firewalls etc? If you
are that's fine, be prepared to back it with effort and we can assist
you, but it isn't a reason to exclude another communication solution,
all implementations should be pluggable.
Peter.
Gregg Wonderly
On 9/29/2010 3:44 PM, Peter Firmstone wrote:
Sim,
Very well said.
+1. Peter.
Sim IJskes - QCG wrote:
On 29-09-10 10:26, Zoltan Juhasz wrote:
I'll think about it a bit more and come back with issues. Let's
discuss
where Jini should be heading on the Internet.
I think, there is no other direction than going internet. Currently
people and
organisations like to make a simple distinction. LAN is safe,
internet is not.
With the proliferation of trojans, and the knowledge to writing
them, the
concept of a safe LAN is impossible te keep. So instead of following
the crowd
with increasing investment in firewalls, IDS technology to keep our
LAN clean,
we should jump in at the other end. Expose our technology to the most
dangerous environment possible. The Internet! A jini enabled device
should
survive and maintain their function, when deployed on the internet.
We should
create best practices for internet deployment and work on the
biggest hurdles
right now, which are:
- lack of broadcast capabilities
- firewalls
- trust relations
Gr. Sim
