Greg Trasuk wrote:
On Tue, 2011-02-08 at 10:49, Gregg Wonderly wrote:
On 2/7/2011 8:44 PM, tras...@trasuk.com wrote:
Seems like this behavior ('isolate proxy') would be something you could specify
as an invocation constraint when you prepare the registrar proxy.
I think that they are focused specifically on the fact that the registrar is
already unmarshalling the proxy before you see it to do proxy preparation. So,
anything it does in the no-args constructor is a point of exposure to DOS attacks.
Right, but the registrar itself is represented by a proxy (i.e.
LookupDiscoveryManager has a 'registrarPreparer' configuration item).
Since this behaviour ('isolate service proxy') is orthogonal to the
lookup method's core functionality, doesn't it make sense to put an
invocation constraint on the _registrar_ proxy, the same as we might put
a 'make sure communication with the registrar is confidential'
constraint?
Cheers,
Greg.
Interesting, I hadn't considered a constraint. It would also be possible
to isolate the registrar's proxy as well, that would be a discovery
constraint however.
For a registrar proxy during discovery, the time that we need to protect
against attack (if we're going to prepare and verify a proxy) is the
unmarshalling period, when foreign code executes, but for the registrar
proxy and discovery, the reference to the proxy and the verification
process is relatively safe as no foreign code is executed. Which is why
the discovery denial of service that I posted earlier only protects the
client during the period where the InputStream is read (Discovery V2
Protocol) and the registrar's proxy unmarshalled, the returned registrar
proxy is not wrapped.
It would also be possible to encapsulate the registrar proxy in
isolation, but I haven't chosen to do this at this stage.
How important is multi threading to proxy's?
With the constraint approach we have to trust the registrar enough for
it to do this for us, we would have to take the registrar at it's word,
unless the platform does it for us. It is possible to add this
functionality to MarshalledInstance (part of the platform). We might
allow the client to set configuration, however that's an all or nothing
approach, it doesn't allow the client a different choice between
different lookup services.
We could make it a privilege, a permission that if granted to the
registrar proxy allows it to unmarshall looked up proxy's without
protection.
But that doesn't feel right either, although it does allow the client to
authenticate the lookup service before deciding to grant permission.
When permission isn't granted, it could simply fall back to the safe
option, without throwing a security exception.
Thoughts?
Peter.
