Miscommunication... as usual :D
Anyway - I was really interested why you find the need for the bootstrap
proxy to be necesarilly a dynamic proxy
(since you seemed to find it very important from the security standpoint)
- wanted to find out whether there were any issues in my thinking about
providing a "code downloading object".
Seems like there are not.
Cheers,
Michal
Peter wrote:
Oh I thought it was part of your SmartProxyWrapper?
Who'd have thought you were talking about my work lol! I wouldn't agree with
me either!
My work:
1. new secure discovery protocols that include registrar codebase url and
signers.
2. authenticate lookup service during disco, grant minimal permissions if auth
successful. If unsuccessful no codebase download no deserialization.
3. lookup service proxy can't unmarshall proxy's from other services (insufficient permission), only has auth for its smart proxy url.
4. lookup service can only return dynamic proxy tokens that the proxy preparer can use to contact and authenticate each service. These tokens are loaded in lookup service proxy ClassLoader (sorry no codebase annotations, no codebase downloads, min permission). Lookup service not granted permission to make network connections, can't unmarshall smart proxys for other services.
5. All communications over trusted connections after auth.
6. Input validation for deserialization.
The code and docs are on github for all to see. The interfaces the tokens
impliment are documented in SafeServiceRegistrar.
The code actually does what I've described above, but don't take my word for
it, check it for youself. :)
If you disagree, don't use it. There is no highlander principle here, you are
free to implement alternatives. In fact I encourage you to do so as this can
only serve to increase understanding.
Cheers,
Peter
Sent from my Samsung device.
Include original message
---- Original message ----
From: Michał Kłeczek<mic...@kleczek.org>
Sent: 15/02/2017 05:00:14 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
They are valid questions and you haven't answered any of them.
I've described _your_ way of thinking (which I do not agree with).
Apache River has many problems both technical and organizational
But I find the idea interesting and was expecting openness
for contributions and open discussion.
This is an open source project and there are no obligations to take part
in the discussion nor answer any questions.
But I find your patronizing statement disincentive to contribute to this
project - especially that you are one of its main contributors.
Regards,
Michal
Peter wrote:
Finding the answer to this question should assist you to discover answers to
many of the other questions you've had.
While I've done my best to answer as many of your questions as I can, time is
limited and I haven't had time to answer all of them or rebutt or confirm all
arguments / assumptions. Sometimes the right questions are more important
than answers.
Regards,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Peter<j...@zeus.net.au>
Sent: 15/02/2017 12:58:55 pm
To: dev@river.apache.org<dev@river.apache.org>
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
The PreferredClassLoader will attempt to download the jar file in order to
get the preferred list.
DownloadPermission should be called DefineClassPermission, I don't think it
will prevent download of the jar per say.
Why must the bootstrap proxy be loaded by the codebase ClassLoader?
Regards,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Michał Kłeczek<mic...@kleczek.org>
Sent: 15/02/2017 06:20:37 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So I've given it some thought and the only explanation I can come up
with is:
1. To create an instance of the bootstrap proxy you need the codebase
annotation.
2. Codebase annotation is needed because you want the bootstrap proxy's
class to be
defined in the proper codebase ClassLoader
3. Since you do not want to allow any code downloads before placing
constraints on the
bootstrap proxy - it has to be a dynamic proxy. That way its class can
be defined by the codebase loader
and yet no code is downloaded
So the overall sequence is as follows:
1. Get the codebase annotation and create the codebase loader
2. Create an instance of a dynamic proxy of a class defined by the
codebase loader
3. IMPORTANT - before creating the proxy instance DO NOT grant any
download permissions
- that way we are sure the proxy does not triggers any code download and
execution due
to it implementing some foreign interfaces
4. Once the proxy is instantiated - grant its ClassLoader download
permissions
5. Place the constraints on the proxy
6. Invoke a remote method on the proxy
I understand the whole thing is to make sure the bootstrap proxy
is defined by the codebase ClassLoader - and the ClassLoader is needed
to be able to
dynamically grant download permissions.
What I DO NOT understand is - why the download permissions are needed at
all?
Since the bootstrap proxy's code MUST be local code - why not simply
have its class
defined by the context ClassLoader?
Since downloading code is done only after authentication anyway - I
don't see the reason to
use DownloadPermissions at all.
The only thing that comes to mind is that it is to make sure the service
is not able to download code from a codebase different than its own.
Which is OK but redundant. The reasoning is:
Since the code of the service proxy is already trusted (we have
established trust before downloading it) -
we can simply place the constraints on the service proxy that instructs
it to only download
code meeting certain criteria.
Am I correct in my thinking?
Thanks,
Michal
Michał Kłeczek wrote:
Let me dig some deeper. Comments inline.
Peter wrote:
Yes the dynamic proxy's are 100% local code. Remember dynamic
proxy's don't have codebase s. :)
Of course they do - look at PreferredClassProvider - the dynamic proxy
class is defined by the codebase loader!
Being a dynamic proxy does not mean there is no codebase.
AtomicMarshalInputStream performs a special input validation on
java.lang.reflect.Proxy thus ensuring the InvocationHandler is also
trusted. If the InvocationHandler doesn't pass the test the proxy's
never created.
Why does it only verify dynamic proxies? Doesn't it verify normal
objects?
The dynamic proxy's put you in direct contact with the service
provider using only local code with input validation constrained over
secure connections (as configured with constraints in force).
I think I've given you enough info now to investigate further.
Ok - so your "token" is the same thing as my SmartProxyWrapper. Let's
call it a "bootstrap proxy", ok?
1. What interface this bootstrap proxy implements?
2 Why do you think it has to be a dynamic proxy (ie. an instance of a
subclass of java.lang.Proxy)?
3. What and when are DownloadPermissions required? How do they add to
the overall security?
I understand the security of service proxies is enforced by the
constraints placed on the bootstrap proxy.
So where is the place for DownloadPermissions?
4. Finally - how is the lookup service proxy verified? Does it also
provide the bootstrap proxy?
If so - what special role does it play in the architecture?
The bootstrap proxy does not have to be provided by the lookup
service, does it?
If it is verified differently - why and how?
Thanks,
Michal
