I think what's happening is we're bumping into the limits of the JVM,
because the JVM can't protect us from DOS, we want to rely on trust.
The DOS we're worrying about here is not wide scale DOS, but individual
JVM DOS.
The JVM can't place any restrictions on the downloaded code, like limits
on %CPU, %Network and %Memory consumption.
Solaris Zones has these features, they were part of the Isolates API
implemented in the MVM and subset is implemented in Java ME CLDC.
JNode has the Isolates API, but it's intended to replace the whole OS.
Tim Blackman was researching using separate JVM's, any ideas?
Cheers,
Peter.
Gregg Wonderly wrote:
On 10/1/2010 4:39 AM, Sim IJskes - QCG wrote:
On 09/29/2010 11:45 PM, 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".
I agree with you. A downloaded class is a specialization of
downloaded data. Or
maybe even not, but lets not go there.
In general terms, a class has more degrees of freedom than data.
Because a class
is executed by a turing complete state machine and most of the time
the machine
executing data is less complete.
Trust is what I was trying to point at. People download XML,
Javascript on web pages, zip archives, executable programs and all
kinds of things what at some point the data, becomes "the semantic
meaning" and gets used by some "machinery" to cause action.
There is never validation done about anything more than structure
(DtD, schema) of things like XML, or "machine magic number" for
executables etc. Only some simple evaluation of "will the machine
accept this input" is done.
With Jini, people are constantly burdened by the whole idea of "what
can we trust about this code", or "how can we prove no harm will come".
The answer is that only through exhaustive means can you do that for
any instance of "the downloaded code", and what httpmd: and other
similar things are about, is "identifying a version" that has been
"evaluated" to be "what you expect".
Web sites publishing source code, binary distributions and other
things that need to be trustworthy, also publish "hashes" of the
"contents" to help people evaluate that they have "the right stuff".
So, I think we have ample ability to provide people multiple levels of
trust assertion and trust evaluation already.
The problem is that we really feel like it needs to be "individual
permissions" because that's the "tightest security model" that we can
see and it seems very attractive to use it. In the end, there are
places where that is necessary, but more often than not, it is a large
barrier which makes it very difficult to say "I trust the code"
trivially.
For example, we don't have mechanisms which would allow a ServiceUI
client, to "see" a service in the registrar, and only after seeing it
and its source, signify trust, and then download code. The original
design has always been around the concept of "you start the VM with
the trust asserted" and then it can only do what you've entrusted it
with.
We need a lot more dynamics so that we can really see how hard it is
to create real, working mechanisms for dynamically changing the trust
relationships between the clients and the services. And it needs to
work remotely so that I can tell a service that it can use another
service through administrative interfaces.
Gregg Wonderly
My personal view on this matter revolves around the burden it puts on
the user.
When i download code and run its installer, i trust the code to well
behave.
When i run the installer i make one big trust decision. I can audit
the files
installed if i'm really paranoid, or a security researcher. When i
run my jini
application, it connects to some registry, downloads a jar into
memory and
executes it. This jar can be same as yesterday or it might not. I
can't tell.
Does it perform the same function?
The basic components are the same, but i see distinct differences. Do
you see
this agility to take off in a corporate environment?
Gr. Sim
