You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Sim IJskes - QCG <si...@qcg.nl> on 2010/09/29 12:23:31 UTC
Re: Towards Internet Jini Services (why)
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
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Towards Internet Jini Services (why)
Posted by Patricia Shanahan <pa...@acm.org>.
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
Another way of looking at it is "Towards Internet Jini Services, (why
not)".
The only way we are going to find out whether Jini is viable on the
Internet is to investigate it and see if there are any issues we cannot
solve. If there is a killer issue, knowing what it is, and hardening
Jini as much as we can, will tell us the minimum properties an intranet
needs to be a safe Jini environment. It would also provide a research
question that might be fed back into universities as a challenge for
security researchers.
I think the objective should be to either make it work, or understand
and be able to state exactly why it cannot be made to work.
Patricia
Re: Towards Internet Jini Services (why)
Posted by Michael McGrady <mi...@gmail.com>.
+1 Take the bull by the horns - solve the problems. Move on! Good show!
On Sep 29, 2010, at 1: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
>>
>>
>
Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
mmcgrady@topiatechnology.com
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 12 of October 2010 08:10:04 Michal Kleczek wrote:
>
> 1. You want to issue a remote call to _retrieve_ annotations whereas I want
> to do that to _verify_ them.
Of course I meant retrieve "codebases" not "annotations"
Michal
Re: PGP
Posted by Michal Kleczek <mk...@contour-technology.com>.
On Tuesday 12 of October 2010 16:13:14 Sim IJskes - QCG wrote:
> On 10/12/2010 04:10 PM, Michal Kleczek wrote:
> > On Tuesday 12 of October 2010 16:04:41 Sim IJskes - QCG wrote:
> >> On 10/12/2010 03:39 PM, Michal Kleczek wrote:
> >>> Or your code is signed with PGP - but I don't have a PGP verifier
> >>> installed. Is it possible for you to provide me with third party PGP
> >>> verifier code that in turn is signed with a standard X509 certificate?
> >>
> >> Why PGP? The PKI is the same. The CA's signing domain related
> >> certificates are creating the inflexibility.
> >
> > Exactly... Hierarchical CAs are inflexible - that's why PGP (or SPKI) :)
>
> Strange reasoning. I'm my own CA. Whats the problem?
Your CA certificate is self-signed. How can I trust it?
Is it possible o build a chain of trust like in SPKI?
Michal
Re: PGP
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/12/2010 04:10 PM, Michal Kleczek wrote:
> On Tuesday 12 of October 2010 16:04:41 Sim IJskes - QCG wrote:
>> On 10/12/2010 03:39 PM, Michal Kleczek wrote:
>>> Or your code is signed with PGP - but I don't have a PGP verifier
>>> installed. Is it possible for you to provide me with third party PGP
>>> verifier code that in turn is signed with a standard X509 certificate?
>>
>> Why PGP? The PKI is the same. The CA's signing domain related
>> certificates are creating the inflexibility.
>
> Exactly... Hierarchical CAs are inflexible - that's why PGP (or SPKI) :)
Strange reasoning. I'm my own CA. Whats the problem?
Gr. Sim
Re: PGP
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 12 of October 2010 16:04:41 Sim IJskes - QCG wrote:
> On 10/12/2010 03:39 PM, Michal Kleczek wrote:
> > Or your code is signed with PGP - but I don't have a PGP verifier
> > installed. Is it possible for you to provide me with third party PGP
> > verifier code that in turn is signed with a standard X509 certificate?
>
> Why PGP? The PKI is the same. The CA's signing domain related
> certificates are creating the inflexibility.
Exactly... Hierarchical CAs are inflexible - that's why PGP (or SPKI) :)
My point actually is - can we make it flexible but still secure?
Michal
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Ok, I think that we've all got pieces of this puzzle and it's a doozy.
We can solve this, by our heads & ideas together.
I've got some thread isolation code that anticipates the StackOverflowError.
Michal's got the idea of using a reflective proxy in an annotation
Object for verification authentication.
So how about this:
Alter or extend MarshalledOutputStream to append the verification
reflective proxy after the String, in the writeAnnotation method.
Then we can use any existing URL scheme, remain compatible with earlier
versions and verify and authenticate the other end and ensure privacy
constraints have been met etc.
Then if the other end authenticates, we trust it.
This can be all isolated on a Unmarshalling Thread in a Single Thread
ExecutorService, where any StackOverflowExceptions are handled and
wrapped as IOExceptions for the client thread and no foreign code runs
or can be downloaded, until we authenticate and grant it.
Cheers,
Peter.
Michal Kleczek wrote:
> On Tuesday 12 of October 2010 15:39:52 Michal Kleczek wrote:
>
>> On Tuesday 12 of October 2010 15:07:07 Sim IJskes - QCG wrote:
>>
>>
>>> I dont like the idea, that we allow full deserialization before we have
>>> had a change to let the IntegrityVerifier have a look at it.
>>>
>> But suppressing recursive readAnnotation already does that!!!
>> Doesn't it?
>>
>
> Even without this we do not run untrusted code.
> What can happen is attacker can send u a corrupted stream that contains of
> Modules annotated with Modules - but no untrusted code will have a chance to
> run.
> In the end you're going to get StackOverflowError and quit.
>
> Michal
>
>
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 12 of October 2010 15:39:52 Michal Kleczek wrote:
> On Tuesday 12 of October 2010 15:07:07 Sim IJskes - QCG wrote:
>
> > I dont like the idea, that we allow full deserialization before we have
> > had a change to let the IntegrityVerifier have a look at it.
>
> But suppressing recursive readAnnotation already does that!!!
> Doesn't it?
Even without this we do not run untrusted code.
What can happen is attacker can send u a corrupted stream that contains of
Modules annotated with Modules - but no untrusted code will have a chance to
run.
In the end you're going to get StackOverflowError and quit.
Michal
PGP
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/12/2010 03:39 PM, Michal Kleczek wrote:
> Or your code is signed with PGP - but I don't have a PGP verifier installed.
> Is it possible for you to provide me with third party PGP verifier code that in
> turn is signed with a standard X509 certificate?
Why PGP? The PKI is the same. The CA's signing domain related
certificates are creating the inflexibility.
Gr. Sim
liberate the CA
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/12/2010 03:39 PM, Michal Kleczek wrote:
> But make it simpler - you have a TLS certificate but you don't have code
> signing certificate (you know - it is much more expensive).
If you haven't got it, create it, or ask you own CA for it. But don't
fall in the trap of https-pki = security. I would like much more freedom
in creating certificates,
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 12 of October 2010 15:07:07 Sim IJskes - QCG wrote:
> On 10/12/2010 02:57 PM, Michal Kleczek wrote:
> >> No you don't. You can delegate it to the IntegrityVerifier. This is the
> >> place where you should check the integrity. You will have enough
> >> information there (coded in the codebase parameter), to load the code,
> >> check endpoints (dns name, ip address, TLS) if wanted, check signatures,
> >> certificates, checksums.
> >
> > Right - but it looks to me we're turning circles right now. Maybe I just
> > don't understand what you're saying so let me describe a scenario that I
> > would like to support:
> > 1. Prerequisite - you and I are logged in to the same Kerberos realm and
> > I know your kerberos principal
> > 2. I got a piece of data - a marshalled object
> > 3. Before I deserialize an object I want to make sure the codebase of the
> > object I got is the one you wanted it to be (regardless of the contents
> > of the jar file I will download later - I'm going to check its integrity
> > later on)
>
> My take on this, is that we should lower the prerequisite, and still
> have a robust implementation. We are talking about the internet are we?
> How many of us share a kerberos realm?
C'mon - that's not fair :) . I've choosen kerberos to show we can (and should)
support something more than PKI stuff.
But make it simpler - you have a TLS certificate but you don't have code
signing certificate (you know - it is much more expensive).
Or your code is signed with PGP - but I don't have a PGP verifier installed.
Is it possible for you to provide me with third party PGP verifier code that in
turn is signed with a standard X509 certificate?
>
> I dont like the idea, that we allow full deserialization before we have
> had a change to let the IntegrityVerifier have a look at it.
But suppressing recursive readAnnotation already does that!!!
Doesn't it?
Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/12/2010 02:57 PM, Michal Kleczek wrote:
>> No you don't. You can delegate it to the IntegrityVerifier. This is the
>> place where you should check the integrity. You will have enough
>> information there (coded in the codebase parameter), to load the code,
>> check endpoints (dns name, ip address, TLS) if wanted, check signatures,
>> certificates, checksums.
>
> Right - but it looks to me we're turning circles right now. Maybe I just don't
> understand what you're saying so let me describe a scenario that I would like
> to support:
> 1. Prerequisite - you and I are logged in to the same Kerberos realm and I
> know your kerberos principal
> 2. I got a piece of data - a marshalled object
> 3. Before I deserialize an object I want to make sure the codebase of the
> object I got is the one you wanted it to be (regardless of the contents of the
> jar file I will download later - I'm going to check its integrity later on)
My take on this, is that we should lower the prerequisite, and still
have a robust implementation. We are talking about the internet are we?
How many of us share a kerberos realm?
I dont like the idea, that we allow full deserialization before we have
had a change to let the IntegrityVerifier have a look at it. And if you
want to fix that, you've created a snake biting its own arse. And we
wont have that do we?
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 12 of October 2010 14:23:44 Sim IJskes - QCG wrote:
> On 10/12/2010 02:12 PM, Michal Kleczek wrote:
> > On Tuesday 12 of October 2010 14:00:14 Sim IJskes - QCG wrote:
> >> It doesn't happen with readUTF(). The first bytes read are the stream
> >> header, (0xac, 0xed, 0, 5), and then the length, then the bytes
> >> composing the string. No parsing of TC constants, and no optional code
> >> paths that can lead to out-of-anything dos attacks. Send it with
> >> writeUTF, read it with a custom function limiting the length of the
> >> string and voila whe have at least made it 1 step more difficult to dos.
> >
> > I understand your arguments but I am still not convinced - you somehow
> > have to send a ProxyTrust instance (or any remote object reference) so
> > that you can verify codebase using it.
>
> No you don't. You can delegate it to the IntegrityVerifier. This is the
> place where you should check the integrity. You will have enough
> information there (coded in the codebase parameter), to load the code,
> check endpoints (dns name, ip address, TLS) if wanted, check signatures,
> certificates, checksums.
Right - but it looks to me we're turning circles right now. Maybe I just don't
understand what you're saying so let me describe a scenario that I would like
to support:
1. Prerequisite - you and I are logged in to the same Kerberos realm and I
know your kerberos principal
2. I got a piece of data - a marshalled object
3. Before I deserialize an object I want to make sure the codebase of the
object I got is the one you wanted it to be (regardless of the contents of the
jar file I will download later - I'm going to check its integrity later on)
Are we talking about the same thing?
Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/12/2010 02:12 PM, Michal Kleczek wrote:
> On Tuesday 12 of October 2010 14:00:14 Sim IJskes - QCG wrote:
>>
>> It doesn't happen with readUTF(). The first bytes read are the stream
>> header, (0xac, 0xed, 0, 5), and then the length, then the bytes
>> composing the string. No parsing of TC constants, and no optional code
>> paths that can lead to out-of-anything dos attacks. Send it with
>> writeUTF, read it with a custom function limiting the length of the
>> string and voila whe have at least made it 1 step more difficult to dos.
>>
>
> I understand your arguments but I am still not convinced - you somehow have to
> send a ProxyTrust instance (or any remote object reference) so that you can
> verify codebase using it.
No you don't. You can delegate it to the IntegrityVerifier. This is the
place where you should check the integrity. You will have enough
information there (coded in the codebase parameter), to load the code,
check endpoints (dns name, ip address, TLS) if wanted, check signatures,
certificates, checksums.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 12 of October 2010 14:00:14 Sim IJskes - QCG wrote:
>
> It doesn't happen with readUTF(). The first bytes read are the stream
> header, (0xac, 0xed, 0, 5), and then the length, then the bytes
> composing the string. No parsing of TC constants, and no optional code
> paths that can lead to out-of-anything dos attacks. Send it with
> writeUTF, read it with a custom function limiting the length of the
> string and voila whe have at least made it 1 step more difficult to dos.
>
I understand your arguments but I am still not convinced - you somehow have to
send a ProxyTrust instance (or any remote object reference) so that you can
verify codebase using it.
You have to assume what it is going to be anyway. I just don't see a real
difference between having custom parsing/instantiation and (limited by not
allowing recursive annotations) parsing/instantiation done by
ObjectInputStream.
If we need this kind of protection I would do it at the lower level - just
have a counting InputStream that throws IOException when a certain limit of
bytes read is reached (it won't be caught and ignored by malicious code since
we don't run any malicious code - at least not yet :) )
Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/12/2010 01:41 PM, Michal Kleczek wrote:
> On Tuesday 12 of October 2010 13:33:09 Sim IJskes - QCG wrote:
>> On 10/12/2010 01:11 PM, Michal Kleczek wrote:
>>> On Tuesday 12 of October 2010 13:08:19 Sim IJskes - QCG wrote:
>>>> On 10/12/2010 12:33 PM, Michal Kleczek wrote:
>>>>> Hmm... I think I would argue that annotation should have the codebase
>>>>> embedded and only issue a remote call to verify this codebase - not to
>>>>> retrieve it.
>>>>>
>>>>> How about we get rid of Module interface and require annotation to be
>>>>> RmiModule (which is final)?
>>>>
>>>> By re/encoding it as a String. So we can harden the MarshallInputStream
>>>> to only accept UTF-8 String with limited length.
>>>
>>> Would that be enough just not to allow recursive readAnnotation() ?
>>> That way our stream would be more compact...
>>
>> It is my perception that you can feed the deserializer anything you
>> want, recursive or not, as long as you limit yourself to the jre
>> classes. The 'check' (at this moment) happens at the cast to String.
>>
>> And by building a babushka in the stream, cause a stackoverflow or
>> heapoverflow (dependend on the implementation) in this way.
>
> But isn't it something that always can happen if the code of objects you
> deserialize has bugs?
It doesn't happen with readUTF(). The first bytes read are the stream
header, (0xac, 0xed, 0, 5), and then the length, then the bytes
composing the string. No parsing of TC constants, and no optional code
paths that can lead to out-of-anything dos attacks. Send it with
writeUTF, read it with a custom function limiting the length of the
string and voila whe have at least made it 1 step more difficult to dos.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 12 of October 2010 13:33:09 Sim IJskes - QCG wrote:
> On 10/12/2010 01:11 PM, Michal Kleczek wrote:
> > On Tuesday 12 of October 2010 13:08:19 Sim IJskes - QCG wrote:
> >> On 10/12/2010 12:33 PM, Michal Kleczek wrote:
> >>> Hmm... I think I would argue that annotation should have the codebase
> >>> embedded and only issue a remote call to verify this codebase - not to
> >>> retrieve it.
> >>>
> >>> How about we get rid of Module interface and require annotation to be
> >>> RmiModule (which is final)?
> >>
> >> By re/encoding it as a String. So we can harden the MarshallInputStream
> >> to only accept UTF-8 String with limited length.
> >
> > Would that be enough just not to allow recursive readAnnotation() ?
> > That way our stream would be more compact...
>
> It is my perception that you can feed the deserializer anything you
> want, recursive or not, as long as you limit yourself to the jre
> classes. The 'check' (at this moment) happens at the cast to String.
>
> And by building a babushka in the stream, cause a stackoverflow or
> heapoverflow (dependend on the implementation) in this way.
But isn't it something that always can happen if the code of objects you
deserialize has bugs?
It does not matter if you read an annotation of "ordinary" object.
So limiting ourselves to:
1. RmiModule as annotation
2. Suppressing recursive annotation read
3. Implementing RmiModule readObject so that it only allows limited length
string as annotation.
4. I guess you have to also do the same in Endpoint implementations (so that
we limit hostname length)
would do the trick...
Wouldn't it?
Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/12/2010 01:11 PM, Michal Kleczek wrote:
> On Tuesday 12 of October 2010 13:08:19 Sim IJskes - QCG wrote:
>> On 10/12/2010 12:33 PM, Michal Kleczek wrote:
>>> Hmm... I think I would argue that annotation should have the codebase
>>> embedded and only issue a remote call to verify this codebase - not to
>>> retrieve it.
>>>
>>> How about we get rid of Module interface and require annotation to be
>>> RmiModule (which is final)?
>>
>> By re/encoding it as a String. So we can harden the MarshallInputStream
>> to only accept UTF-8 String with limited length.
>
> Would that be enough just not to allow recursive readAnnotation() ?
> That way our stream would be more compact...
It is my perception that you can feed the deserializer anything you
want, recursive or not, as long as you limit yourself to the jre
classes. The 'check' (at this moment) happens at the cast to String.
And by building a babushka in the stream, cause a stackoverflow or
heapoverflow (dependend on the implementation) in this way.
I dont see an easy way to implement a loadOnlyThisClass(Class cls)
member function. And changing all the methods where codebase is coded as
a String, is also not my favorite.
My proposal:
Code 'codebase annotation' as a String. Add a verifier that loads the
code and checks signing, and allow actual class instantiation to reuse
the bytes that have already been downloaded by the verifier.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 12 of October 2010 13:08:19 Sim IJskes - QCG wrote:
> On 10/12/2010 12:33 PM, Michal Kleczek wrote:
> > Hmm... I think I would argue that annotation should have the codebase
> > embedded and only issue a remote call to verify this codebase - not to
> > retrieve it.
> >
> > How about we get rid of Module interface and require annotation to be
> > RmiModule (which is final)?
>
> By re/encoding it as a String. So we can harden the MarshallInputStream
> to only accept UTF-8 String with limited length.
Would that be enough just not to allow recursive readAnnotation() ?
That way our stream would be more compact...
Michal
Re: Towards Internet Jini Services (trust)
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 10/12/2010 6:08 AM, Sim IJskes - QCG wrote:
> On 10/12/2010 12:33 PM, Michal Kleczek wrote:
>> Hmm... I think I would argue that annotation should have the codebase embedded
>> and only issue a remote call to verify this codebase - not to retrieve it.
>>
>> How about we get rid of Module interface and require annotation to be
>> RmiModule (which is final)?
>
> By re/encoding it as a String. So we can harden the MarshallInputStream to only
> accept UTF-8 String with limited length.
Remember that, you can serialize to a byte stream, sign those bytes, UUEncode or
otherwise make it an ASCII/UTF-8 string.
Imagine then, that you put "rmimod:/" on the front of that string and return it
as the annotation.
For the client, you can create a protocol handler for rmimod, which takes the
"path" value, converts to binary, checks the signature, extracts the byte stream
and then returns that byte stream from the URLStreamHandler.
Gregg Wonderly
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/12/2010 12:33 PM, Michal Kleczek wrote:
> Hmm... I think I would argue that annotation should have the codebase embedded
> and only issue a remote call to verify this codebase - not to retrieve it.
>
> How about we get rid of Module interface and require annotation to be
> RmiModule (which is final)?
By re/encoding it as a String. So we can harden the MarshallInputStream
to only accept UTF-8 String with limited length.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Hmm... I think I would argue that annotation should have the codebase embedded
and only issue a remote call to verify this codebase - not to retrieve it.
How about we get rid of Module interface and require annotation to be
RmiModule (which is final)?
Michal
[snipped the whole discussion below since it looked like it was unmanageable
anymore]
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Code Signing has the additional advantage of preventing classes with
different Certificate's from sharing a package. It would also allow
service providers to sign their jar files to prevent them being shared
with other services.
Cheers,
Peter.
Peter Firmstone wrote:
> Peter Firmstone wrote:
>> Note this code doesn't protect against DNS cache poisoning attacks.
>> We could easily extend this to require the jar file be signed as per
>> Sim's suggestion, by a Certificate[] known to the Service, currently
>> set to null in the CodeSource grant, easily passed into the
>> constructor or perhaps as static list, or perhaps even supplied by
>> the authentication proxy.
>
> The CodeSource (containing Certificate[]'s) PermissionGrant, would
> contain something like a ClassLoadingPermission.
>
> The DownloadPermission protects against unauthorised download, while
> the ClassLoadingPermission would protect against unauthorised class
> loading.
>
> The ClassLoadingPermission would only apply if the downloaded codebase
> is signed by the required certificates, provided in advance by the proxy.
>
> Any untrusted public http codebase server will be suitable.
>
> If we isolate unmarshalling to an Executor Service Thread, handling
> error conditions like StackOverflowError, were starting to look
> relatively secure. We can have Socket time-outs too. The Executor
> service thread doesn't run untrusted code, it's only really protecting
> against an untrusted http codebase from supplying excessively large
> files.
>
> Cheers,
>
> Peter.
>>
>> The Certificate[] would guarantee that a DNS cache poisoning attack
>> couldn't work.
>>
>> /*
>> * Licensed to the Apache Software Foundation (ASF) under one
>> * or more contributor license agreements. See the NOTICE file
>> * distributed with this work for additional information
>> * regarding copyright ownership. The ASF licenses this file
>> * to you under the Apache License, Version 2.0 (the
>> * "License"); you may not use this file except in compliance
>> * with the License. You may obtain a copy of the License at
>> *
>> * http://www.apache.org/licenses/LICENSE-2.0
>> *
>> * Unless required by applicable law or agreed to in writing, software
>> * distributed under the License is distributed on an "AS IS" BASIS,
>> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> implied.
>> * See the License for the specific language governing permissions and
>> * limitations under the License.
>> */
>>
>> package org.apache.river.imp.security.io;
>>
>> import java.io.IOException;
>> import java.io.OutputStream;
>> import java.lang.reflect.Proxy;
>> import java.util.Collection;
>> import net.jini.io.MarshalOutputStream;
>>
>> /**
>> * This code was inspired by Michal Kleczek's suggestions for solving the
>> * DOS hole during unmarshalling of untrusted code.
>> *
>> * @author Peter Firmstone
>> */
>> public class AuthMarshalOutputStream extends MarshalOutputStream {
>> private final Proxy proxy;
>> public AuthMarshalOutputStream(OutputStream out,
>> Collection context,
>> Proxy authenticationProxy)
>> throws IOException
>> {
>> super(out, context);
>> if (authenticationProxy == null) {
>> throw new NullPointerException("Null Authentication Proxy");
>> }
>> proxy = authenticationProxy;
>> }
>> @Override
>> protected void writeAnnotation(String annotation) throws
>> IOException {
>> writeObject(annotation);
>> writeObject(proxy);
>> }
>>
>> }
>>
>>
>> /*
>> * Licensed to the Apache Software Foundation (ASF) under one
>> * or more contributor license agreements. See the NOTICE file
>> * distributed with this work for additional information
>> * regarding copyright ownership. The ASF licenses this file
>> * to you under the Apache License, Version 2.0 (the
>> * "License"); you may not use this file except in compliance
>> * with the License. You may obtain a copy of the License at
>> *
>> * http://www.apache.org/licenses/LICENSE-2.0
>> *
>> * Unless required by applicable law or agreed to in writing, software
>> * distributed under the License is distributed on an "AS IS" BASIS,
>> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> implied.
>> * See the License for the specific language governing permissions and
>> * limitations under the License.
>> */
>>
>> package org.apache.river.imp.security.io;
>>
>> import java.io.IOException;
>> import java.io.InputStream;
>> import java.io.InvalidObjectException;
>> import java.io.ObjectStreamClass;
>> import java.lang.reflect.Proxy;
>> import java.net.MalformedURLException;
>> import java.net.URL;
>> import java.security.CodeSource;
>> import java.security.Policy;
>> import java.security.cert.Certificate;
>> import java.util.ArrayList;
>> import java.util.Collection;
>> import java.util.HashMap;
>> import java.util.List;
>> import java.util.Map;
>> import java.util.StringTokenizer;
>> import net.jini.io.MarshalInputStream;
>> import net.jini.loader.ClassLoading;
>> import net.jini.loader.DownloadPermission;
>> import net.jini.security.ProxyPreparer;
>> import org.apache.river.api.security.PermissionGrant;
>> import org.apache.river.api.security.PermissionGrantBuilder;
>> import org.apache.river.api.security.RevokeableDynamicPolicy;
>>
>> /**
>> * AuthMarshalInputStream requires the AuthMarshalOutputStream to send
>> a proxy
>> * in order to authenticate itself, it is best if the size of this
>> proxy is
>> * kept to a minimum by only implementing ProxyPreparer and
>> RemoteMethodControl.
>> *
>> * Once the remote end has authenticated, the Annotation string can be
>> read
>> * and a Class file returned.
>> *
>> * The AuthMarshalInputStream will dynamically grant
>> DownloadPermission to the
>> * each URL CodeSource if the Server authenticates itself.
>> *
>> * Note that the DownloadPermission is not granted to the Server
>> Principal
>> * but to the CodeSource that the Server wants the client to download.
>> *
>> * Authentication is only used to determine if we trust the server to
>> inform
>> * us of a suitable URL for download. Once DownloadPermission has
>> been granted
>> * to the CodeSource, the codebase (jar file) can be downloaded.
>> *
>> * Authentication is only performed once for each codebase String.
>> *
>> * @author Peter Firmstone
>> */
>> public class AuthMarshalInputStream extends MarshalInputStream {
>>
>> /**
>> * maps keywords for primitive types and void to corresponding
>> * Class objects
>> **/
>> private static final Map<String,Class> specialClasses
>> = new HashMap<String,Class>(9);
>> static {
>> specialClasses.put("boolean", boolean.class);
>> specialClasses.put("byte", byte.class);
>> specialClasses.put("char", char.class);
>> specialClasses.put("short", short.class);
>> specialClasses.put("int", int.class);
>> specialClasses.put("long", long.class);
>> specialClasses.put("float", float.class);
>> specialClasses.put("double", double.class);
>> specialClasses.put("void", void.class);
>> }
>> private static final DownloadPermission[] perm = {new
>> DownloadPermission()};
>> private static List<String> dynamicGrants = new
>> ArrayList<String>();
>>
>> /**
>> * value to pass as the "default loader" argument to loadClass and
>> * loadProxyClass
>> **/
>> private final ClassLoader defaultLoader;
>>
>> /** true if this stream verifies codebase integrity */
>> private final boolean verifyCodebaseIntegrity;
>>
>> /** loader to pass to Security.verifyCodebaseIntegrity */
>> private final ClassLoader verifierLoader;
>>
>> /**
>> * if false, pass null codebase values to loadClass and
>> * loadProxyClass methods; if true, pass codebase values from
>> * stream class annotations
>> **/
>> private boolean usingCodebaseAnnotations;
>> private final ProxyPreparer preparer;
>>
>> /**
>> * Creates a new <code>AuthMarshalInputStream</code> that reads
>> * marshalled data from the specified underlying
>> * <code>InputStream</code>.
>> *
>> * <p>This constructor passes <code>in</code> to the superclass
>> * constructor that has an <code>InputStream</code> parameter.
>> *
>> * <p><code>defaultLoader</code> will be passed as the
>> * <code>defaultLoader</code> argument to {@link
>> * ClassLoading#loadClass ClassLoading.loadClass} and {@link
>> * ClassLoading#loadProxyClass ClassLoading.loadProxyClass}
>> * whenever those methods are invoked by {@link #resolveClass
>> * resolveClass} and {@link #resolveProxyClass resolveProxyClass}.
>> *
>> * <p>If <code>verifyCodebaseIntegrity</code> is
>> * <code>true</code>, then the created stream will verify that all
>> * codebase annotation URLs that are used to load classes resolved
>> * by the stream provide content integrity, and whenever {@link
>> * Security#verifyCodebaseIntegrity
>> * Security.verifyCodebaseIntegrity} is invoked to enforce that
>> * verification, <code>verifierLoader</code> will be passed as the
>> * <code>loader</code> argument. See {@link
>> * ClassLoading#loadClass ClassLoading.loadClass} and {@link
>> * ClassLoading#loadProxyClass ClassLoading.loadProxyClass} for
>> * details of how codebase integrity verification is performed.
>> *
>> * <p><code>context</code> will be used as the return value of the
>> * created stream's {@link #getObjectStreamContext
>> * getObjectStreamContext} method.
>> *
>> * @param in the input stream to read marshalled data from
>> *
>> * @param defaultLoader the class loader value (possibly
>> * <code>null</code>) to pass as the <code>defaultLoader</code>
>> * argument to <code>ClassLoading</code> methods
>> *
>> * @param verifyCodebaseIntegrity if <code>true</code>, this
>> * stream will verify that codebase annotation URLs used to load
>> * classes resolved by this stream provide content integrity
>> *
>> * @param verifierLoader the class loader value (possibly
>> * <code>null</code>) to pass to
>> * <code>Security.verifyCodebaseIntegrity</code>, if
>> * <code>verifyCodebaseIntegrity</code> is <code>true</code>
>> *
>> * @param context the collection of context information objects to
>> * be returned by this stream's {@link #getObjectStreamContext
>> * getObjectStreamContext} method
>> *
>> * @param preparer the proxy preparer used to authenticate the server
>> * prior to downloading any classes.
>> *
>> * @throws IOException if the superclass's constructor throws an
>> * <code>IOException</code>
>> *
>> * @throws SecurityException if the superclass's constructor
>> * throws a <code>SecurityException</code>
>> *
>> * @throws NullPointerException if <code>in</code> or
>> * <code>context</code> is <code>null</code>
>> **/
>>
>> public AuthMarshalInputStream(InputStream in,
>> ClassLoader defaultLoader,
>> boolean verifyCodebaseIntegrity,
>> ClassLoader verifierLoader,
>> Collection context,
>> ProxyPreparer preparer )
>> throws IOException
>> {
>> super (in, defaultLoader, verifyCodebaseIntegrity, verifierLoader,
>> context);
>> this.defaultLoader = defaultLoader;
>> this.verifyCodebaseIntegrity = verifyCodebaseIntegrity;
>> this.verifierLoader = verifierLoader;
>> this.preparer = preparer;
>> }
>>
>> // Inherit documentation from MarshalInputStream
>> @Override
>> public void useCodebaseAnnotations() {
>> usingCodebaseAnnotations = true;
>> super.useCodebaseAnnotations();
>> }
>>
>> // Inherit documentation from MarshalInputStream
>> @Override
>> protected Class resolveClass(ObjectStreamClass classDesc)
>> throws IOException, ClassNotFoundException
>> {
>> if (classDesc == null) {
>> throw new NullPointerException();
>> }
>>
>> // must always consume annotation written by MarshalOutputStream
>> String annotation = readAnnotation();
>> String codebase = usingCodebaseAnnotations ? annotation : null;
>> authenticate(codebase);
>> String name = classDesc.getName();
>> try {
>> return ClassLoading.loadClass(codebase,
>> name,
>> defaultLoader,
>> verifyCodebaseIntegrity,
>> verifierLoader);
>> } catch (ClassNotFoundException e) {
>> Class c = specialClasses.get(name);
>> if (c != null) {
>> return c;
>> } else {
>> throw e;
>> }
>> }
>> }
>>
>> // Inherit documentation from MarshalInputStream
>> @Override
>> protected Class resolveProxyClass(String[] interfaceNames)
>> throws IOException, ClassNotFoundException
>> {
>> for (int i = 0; i < interfaceNames.length; i++) {
>> if (interfaceNames[i] == null) {
>> throw new NullPointerException();
>> }
>> }
>>
>> // must always consume annotation written by MarshalOutputStream
>> String annotation = readAnnotation();
>> String codebase = usingCodebaseAnnotations ? annotation : null;
>> authenticate(codebase);
>> return ClassLoading.loadProxyClass(codebase,
>> interfaceNames,
>> defaultLoader,
>> verifyCodebaseIntegrity,
>> verifierLoader);
>> }
>> private void authenticate(String codebase)
>> throws IOException, ClassNotFoundException{
>> // Always read the proxy from the AuthMarshalInputStream
>> Object proxy = readObject();
>> if (codebase == null) return;
>> if (dynamicGrants.contains(codebase)) return;
>> try {
>> //Authenticate
>> preparer.prepareProxy(proxy); // Dynamically
>> Grant DownloadPermission for each URL via a
>> // CodeSource grant.
>> Policy policy = Policy.getPolicy();
>> if (policy instanceof RevokeableDynamicPolicy){
>> StringTokenizer st = new StringTokenizer(codebase); // divide
>> by spaces
>> URL[] urls = new URL[st.countTokens()];
>> for (int i = 0; st.hasMoreTokens(); i++) {
>> urls[i] = new URL(st.nextToken());
>> }
>> PermissionGrantBuilder pgb
>> = ((RevokeableDynamicPolicy) policy).getGrantBuilder();
>> pgb.permissions(perm);
>> int l = urls.length;
>> List<PermissionGrant> grants = new ArrayList<PermissionGrant>(l);
>> for (int i = 0; i < l; i++){
>> CodeSource cs = new CodeSource(urls[i], (Certificate[])
>> null);
>> PermissionGrant pg = pgb.codeSource(cs).build();
>> grants.add(pg);
>> }
>> ((RevokeableDynamicPolicy) policy).grant(grants);
>> }
>> dynamicGrants.add(codebase);
>> } catch (SecurityException e) {
>> throw new IOException(e);
>> } catch (MalformedURLException e){
>> throw new IOException(e);
>> }
>> }
>> }
>>
>>
>
>
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Note this code doesn't protect against DNS cache poisoning attacks.
> We could easily extend this to require the jar file be signed as per
> Sim's suggestion, by a Certificate[] known to the Service, currently
> set to null in the CodeSource grant, easily passed into the
> constructor or perhaps as static list, or perhaps even supplied by the
> authentication proxy.
The CodeSource (containing Certificate[]'s) PermissionGrant, would
contain something like a ClassLoadingPermission.
The DownloadPermission protects against unauthorised download, while the
ClassLoadingPermission would protect against unauthorised class loading.
The ClassLoadingPermission would only apply if the downloaded codebase
is signed by the required certificates, provided in advance by the proxy.
Any untrusted public http codebase server will be suitable.
If we isolate unmarshalling to an Executor Service Thread, handling
error conditions like StackOverflowError, were starting to look
relatively secure. We can have Socket time-outs too. The Executor
service thread doesn't run untrusted code, it's only really protecting
against an untrusted http codebase from supplying excessively large files.
Cheers,
Peter.
>
> The Certificate[] would guarantee that a DNS cache poisoning attack
> couldn't work.
>
> /*
> * Licensed to the Apache Software Foundation (ASF) under one
> * or more contributor license agreements. See the NOTICE file
> * distributed with this work for additional information
> * regarding copyright ownership. The ASF licenses this file
> * to you under the Apache License, Version 2.0 (the
> * "License"); you may not use this file except in compliance
> * with the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
> package org.apache.river.imp.security.io;
>
> import java.io.IOException;
> import java.io.OutputStream;
> import java.lang.reflect.Proxy;
> import java.util.Collection;
> import net.jini.io.MarshalOutputStream;
>
> /**
> * This code was inspired by Michal Kleczek's suggestions for solving the
> * DOS hole during unmarshalling of untrusted code.
> *
> * @author Peter Firmstone
> */
> public class AuthMarshalOutputStream extends MarshalOutputStream {
> private final Proxy proxy;
> public AuthMarshalOutputStream(OutputStream out,
> Collection context,
> Proxy authenticationProxy)
> throws IOException
> {
> super(out, context);
> if (authenticationProxy == null) {
> throw new NullPointerException("Null Authentication Proxy");
> }
> proxy = authenticationProxy;
> }
> @Override
> protected void writeAnnotation(String annotation) throws IOException {
> writeObject(annotation);
> writeObject(proxy);
> }
>
> }
>
>
> /*
> * Licensed to the Apache Software Foundation (ASF) under one
> * or more contributor license agreements. See the NOTICE file
> * distributed with this work for additional information
> * regarding copyright ownership. The ASF licenses this file
> * to you under the Apache License, Version 2.0 (the
> * "License"); you may not use this file except in compliance
> * with the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
> package org.apache.river.imp.security.io;
>
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.InvalidObjectException;
> import java.io.ObjectStreamClass;
> import java.lang.reflect.Proxy;
> import java.net.MalformedURLException;
> import java.net.URL;
> import java.security.CodeSource;
> import java.security.Policy;
> import java.security.cert.Certificate;
> import java.util.ArrayList;
> import java.util.Collection;
> import java.util.HashMap;
> import java.util.List;
> import java.util.Map;
> import java.util.StringTokenizer;
> import net.jini.io.MarshalInputStream;
> import net.jini.loader.ClassLoading;
> import net.jini.loader.DownloadPermission;
> import net.jini.security.ProxyPreparer;
> import org.apache.river.api.security.PermissionGrant;
> import org.apache.river.api.security.PermissionGrantBuilder;
> import org.apache.river.api.security.RevokeableDynamicPolicy;
>
> /**
> * AuthMarshalInputStream requires the AuthMarshalOutputStream to send
> a proxy
> * in order to authenticate itself, it is best if the size of this
> proxy is
> * kept to a minimum by only implementing ProxyPreparer and
> RemoteMethodControl.
> *
> * Once the remote end has authenticated, the Annotation string can be
> read
> * and a Class file returned.
> *
> * The AuthMarshalInputStream will dynamically grant DownloadPermission
> to the
> * each URL CodeSource if the Server authenticates itself.
> *
> * Note that the DownloadPermission is not granted to the Server Principal
> * but to the CodeSource that the Server wants the client to download.
> *
> * Authentication is only used to determine if we trust the server to
> inform
> * us of a suitable URL for download. Once DownloadPermission has been
> granted
> * to the CodeSource, the codebase (jar file) can be downloaded.
> *
> * Authentication is only performed once for each codebase String.
> *
> * @author Peter Firmstone
> */
> public class AuthMarshalInputStream extends MarshalInputStream {
>
> /**
> * maps keywords for primitive types and void to corresponding
> * Class objects
> **/
> private static final Map<String,Class> specialClasses
> = new HashMap<String,Class>(9);
> static {
> specialClasses.put("boolean", boolean.class);
> specialClasses.put("byte", byte.class);
> specialClasses.put("char", char.class);
> specialClasses.put("short", short.class);
> specialClasses.put("int", int.class);
> specialClasses.put("long", long.class);
> specialClasses.put("float", float.class);
> specialClasses.put("double", double.class);
> specialClasses.put("void", void.class);
> }
> private static final DownloadPermission[] perm = {new
> DownloadPermission()};
> private static List<String> dynamicGrants = new ArrayList<String>();
>
> /**
> * value to pass as the "default loader" argument to loadClass and
> * loadProxyClass
> **/
> private final ClassLoader defaultLoader;
>
> /** true if this stream verifies codebase integrity */
> private final boolean verifyCodebaseIntegrity;
>
> /** loader to pass to Security.verifyCodebaseIntegrity */
> private final ClassLoader verifierLoader;
>
> /**
> * if false, pass null codebase values to loadClass and
> * loadProxyClass methods; if true, pass codebase values from
> * stream class annotations
> **/
> private boolean usingCodebaseAnnotations;
> private final ProxyPreparer preparer;
>
> /**
> * Creates a new <code>AuthMarshalInputStream</code> that reads
> * marshalled data from the specified underlying
> * <code>InputStream</code>.
> *
> * <p>This constructor passes <code>in</code> to the superclass
> * constructor that has an <code>InputStream</code> parameter.
> *
> * <p><code>defaultLoader</code> will be passed as the
> * <code>defaultLoader</code> argument to {@link
> * ClassLoading#loadClass ClassLoading.loadClass} and {@link
> * ClassLoading#loadProxyClass ClassLoading.loadProxyClass}
> * whenever those methods are invoked by {@link #resolveClass
> * resolveClass} and {@link #resolveProxyClass resolveProxyClass}.
> *
> * <p>If <code>verifyCodebaseIntegrity</code> is
> * <code>true</code>, then the created stream will verify that all
> * codebase annotation URLs that are used to load classes resolved
> * by the stream provide content integrity, and whenever {@link
> * Security#verifyCodebaseIntegrity
> * Security.verifyCodebaseIntegrity} is invoked to enforce that
> * verification, <code>verifierLoader</code> will be passed as the
> * <code>loader</code> argument. See {@link
> * ClassLoading#loadClass ClassLoading.loadClass} and {@link
> * ClassLoading#loadProxyClass ClassLoading.loadProxyClass} for
> * details of how codebase integrity verification is performed.
> *
> * <p><code>context</code> will be used as the return value of the
> * created stream's {@link #getObjectStreamContext
> * getObjectStreamContext} method.
> *
> * @param in the input stream to read marshalled data from
> *
> * @param defaultLoader the class loader value (possibly
> * <code>null</code>) to pass as the <code>defaultLoader</code>
> * argument to <code>ClassLoading</code> methods
> *
> * @param verifyCodebaseIntegrity if <code>true</code>, this
> * stream will verify that codebase annotation URLs used to load
> * classes resolved by this stream provide content integrity
> *
> * @param verifierLoader the class loader value (possibly
> * <code>null</code>) to pass to
> * <code>Security.verifyCodebaseIntegrity</code>, if
> * <code>verifyCodebaseIntegrity</code> is <code>true</code>
> *
> * @param context the collection of context information objects to
> * be returned by this stream's {@link #getObjectStreamContext
> * getObjectStreamContext} method
> *
> * @param preparer the proxy preparer used to authenticate the server
> * prior to downloading any classes.
> *
> * @throws IOException if the superclass's constructor throws an
> * <code>IOException</code>
> *
> * @throws SecurityException if the superclass's constructor
> * throws a <code>SecurityException</code>
> *
> * @throws NullPointerException if <code>in</code> or
> * <code>context</code> is <code>null</code>
> **/
>
> public AuthMarshalInputStream(InputStream in,
> ClassLoader defaultLoader,
> boolean verifyCodebaseIntegrity,
> ClassLoader verifierLoader,
> Collection context,
> ProxyPreparer preparer )
> throws IOException
> {
> super (in, defaultLoader, verifyCodebaseIntegrity, verifierLoader,
> context);
> this.defaultLoader = defaultLoader;
> this.verifyCodebaseIntegrity = verifyCodebaseIntegrity;
> this.verifierLoader = verifierLoader;
> this.preparer = preparer;
> }
>
> // Inherit documentation from MarshalInputStream
> @Override
> public void useCodebaseAnnotations() {
> usingCodebaseAnnotations = true;
> super.useCodebaseAnnotations();
> }
>
> // Inherit documentation from MarshalInputStream
> @Override
> protected Class resolveClass(ObjectStreamClass classDesc)
> throws IOException, ClassNotFoundException
> {
> if (classDesc == null) {
> throw new NullPointerException();
> }
>
> // must always consume annotation written by MarshalOutputStream
> String annotation = readAnnotation();
> String codebase = usingCodebaseAnnotations ? annotation : null;
> authenticate(codebase);
> String name = classDesc.getName();
> try {
> return ClassLoading.loadClass(codebase,
> name,
> defaultLoader,
> verifyCodebaseIntegrity,
> verifierLoader);
> } catch (ClassNotFoundException e) {
> Class c = specialClasses.get(name);
> if (c != null) {
> return c;
> } else {
> throw e;
> }
> }
> }
>
> // Inherit documentation from MarshalInputStream
> @Override
> protected Class resolveProxyClass(String[] interfaceNames)
> throws IOException, ClassNotFoundException
> {
> for (int i = 0; i < interfaceNames.length; i++) {
> if (interfaceNames[i] == null) {
> throw new NullPointerException();
> }
> }
>
> // must always consume annotation written by MarshalOutputStream
> String annotation = readAnnotation();
> String codebase = usingCodebaseAnnotations ? annotation : null;
> authenticate(codebase);
> return ClassLoading.loadProxyClass(codebase,
> interfaceNames,
> defaultLoader,
> verifyCodebaseIntegrity,
> verifierLoader);
> }
> private void authenticate(String codebase)
> throws IOException, ClassNotFoundException{
> // Always read the proxy from the AuthMarshalInputStream
> Object proxy = readObject();
> if (codebase == null) return;
> if (dynamicGrants.contains(codebase)) return;
> try {
> //Authenticate
> preparer.prepareProxy(proxy); // Dynamically Grant
> DownloadPermission for each URL via a
> // CodeSource grant.
> Policy policy = Policy.getPolicy();
> if (policy instanceof RevokeableDynamicPolicy){
> StringTokenizer st = new StringTokenizer(codebase); // divide
> by spaces
> URL[] urls = new URL[st.countTokens()];
> for (int i = 0; st.hasMoreTokens(); i++) {
> urls[i] = new URL(st.nextToken());
> }
> PermissionGrantBuilder pgb
> = ((RevokeableDynamicPolicy) policy).getGrantBuilder();
> pgb.permissions(perm);
> int l = urls.length;
> List<PermissionGrant> grants = new ArrayList<PermissionGrant>(l);
> for (int i = 0; i < l; i++){
> CodeSource cs = new CodeSource(urls[i], (Certificate[]) null);
> PermissionGrant pg = pgb.codeSource(cs).build();
> grants.add(pg);
> }
> ((RevokeableDynamicPolicy) policy).grant(grants);
> }
> dynamicGrants.add(codebase);
> } catch (SecurityException e) {
> throw new IOException(e);
> } catch (MalformedURLException e){
> throw new IOException(e);
> }
> }
> }
>
>
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Michal Kleczek wrote:
> On Tuesday 12 of October 2010 00:27:12 Peter Firmstone wrote:
>
>> Michal Kleczek wrote:
>>
>>> On Monday 11 of October 2010 15:41:46 Peter Firmstone wrote:
>>>
>>>> What about the case where a Module depends on another Module?
>>>>
>>>> I'm guessing that was the intent.
>>>>
>>> Actually - no :)
>>>
>>> There are two different things to consider:
>>>
>>> 1. Module dependencies (which I actually did not think about too much).
>>>
>> Actually I'm thinking there shouldn't be any dependencies, other than
>> the Jini Platform and ServiceAPI, which has been used to obtain the
>> Module.
>>
>
> This is true as long as we have one special ClassLoader that loads
> ServiceAPIs. That is the case with current Jini and has its ramifications.
>
> Once you think about peer class loading model where different versions of the
> same class (even ServiceAPI class) can coexist you need Module dependencies.
>
> But let's not go there at this moment.
>
Hi Michal,
I think we can go there now.
When you think about versioning, it requires a management framework,
since River is a platform implementation, choosing one framework would
require all downstream users do the same, it would not be widely
supported. But we can put suitable programming hooks in place, which I
think is what your trying to do with your secure marshal stream, which
may be a very good idea in concept, but probably something we're not
quite ready for, we're still trying to understand the impact of versioning.
I did raise a concern about handing a ClassLoader to downloaded code,
but the Module service is really about injecting a management framework,
it probably should be a singleton, under certain circumstances, it might
be reasonable to give the downloaded code a ClassLoader reference. To
protect the ClassLoader you could use a GuardObject.
An example version management framework we discussed earlier was OSGi,
there are two ways OSGi can be used:
1. As an embedded framework: runs inside River, in the application
Namespace, proxy's would be outside OSGi's namespace, all Service
API and Jini Platform classes would be visible to OSGi.
2. As the controlling framework: River runs inside OSGi and is under
version control.
Since we have no control over remote JVM's, we cannot dictate that
another JVM run OSGi, in case 1 or 2, we'd require the remote node to
discover our proxy. Also since we are discovering other services, we
need to honor the Service API which they have installed too.
Versioning of Service API:
If we have two versions of a Service API, they must be compatible in
both directions, neither can have additional classes or interface
methods, only their internal class implementation can change. As soon
as there is an incompatible change in the Service API, they become
different services, one cannot discover the other, this is part of the
ServiceRegistrar's contract. Since incompatible versions produce
different services, we might as well just make them different services.
However versioned Service API might be something that you utilise
between different OSGi nodes with your Module service, I'd quite happily
support this as a subproject, if you're interested in exploring it
further, it's still early days, versioning is a very difficult unsolved
topic. I'm impressed at how quickly you're able to write up your code.
You obviously have a good understanding of how to use the Jini API, we
need more people like yourself to be part of River.
I've attached some code below which requires a reflective proxy to
authenticate itself prior to allowing a URL codebase download. I know
this just takes the most appealing idea from your code, to authenticate
using a reflective proxy prior to permitting codebase downloads. The
proxy is used for nothing but authentication and the codebase string
remains, I've appended the code below.
Note this code doesn't protect against DNS cache poisoning attacks. We
could easily extend this to require the jar file be signed as per Sim's
suggestion, by a known Certificate[], currently set to null in the
CodeSource grant, easily passed into the constructor or perhaps as
static list, or perhaps even supplied by the authentication proxy.
The Certificate[] would guarantee that a DNS cache poisoning attack
couldn't work.
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.river.imp.security.io;
import java.io.IOException;
import java.io.OutputStream;
import java.lang.reflect.Proxy;
import java.util.Collection;
import net.jini.io.MarshalOutputStream;
/**
* This code was inspired by Michal Kleczek's suggestions for solving the
* DOS hole during unmarshalling of untrusted code.
*
* @author Peter Firmstone
*/
public class AuthMarshalOutputStream extends MarshalOutputStream {
private final Proxy proxy;
public AuthMarshalOutputStream(OutputStream out,
Collection context,
Proxy authenticationProxy)
throws IOException
{
super(out, context);
if (authenticationProxy == null) {
throw new NullPointerException("Null Authentication Proxy");
}
proxy = authenticationProxy;
}
@Override
protected void writeAnnotation(String annotation) throws IOException {
writeObject(annotation);
writeObject(proxy);
}
}
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.river.imp.security.io;
import java.io.IOException;
import java.io.InputStream;
import java.io.InvalidObjectException;
import java.io.ObjectStreamClass;
import java.lang.reflect.Proxy;
import java.net.MalformedURLException;
import java.net.URL;
import java.security.CodeSource;
import java.security.Policy;
import java.security.cert.Certificate;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.StringTokenizer;
import net.jini.io.MarshalInputStream;
import net.jini.loader.ClassLoading;
import net.jini.loader.DownloadPermission;
import net.jini.security.ProxyPreparer;
import org.apache.river.api.security.PermissionGrant;
import org.apache.river.api.security.PermissionGrantBuilder;
import org.apache.river.api.security.RevokeableDynamicPolicy;
/**
* AuthMarshalInputStream requires the AuthMarshalOutputStream to send a
proxy
* in order to authenticate itself, it is best if the size of this proxy is
* kept to a minimum by only implementing ProxyPreparer and
RemoteMethodControl.
*
* Once the remote end has authenticated, the Annotation string can be read
* and a Class file returned.
*
* The AuthMarshalInputStream will dynamically grant DownloadPermission
to the
* each URL CodeSource if the Server authenticates itself.
*
* Note that the DownloadPermission is not granted to the Server Principal
* but to the CodeSource that the Server wants the client to download.
*
* Authentication is only used to determine if we trust the server to inform
* us of a suitable URL for download. Once DownloadPermission has been
granted
* to the CodeSource, the codebase (jar file) can be downloaded.
*
* Authentication is only performed once for each codebase String.
*
* @author Peter Firmstone
*/
public class AuthMarshalInputStream extends MarshalInputStream {
/**
* maps keywords for primitive types and void to corresponding
* Class objects
**/
private static final Map<String,Class> specialClasses
= new HashMap<String,Class>(9);
static {
specialClasses.put("boolean", boolean.class);
specialClasses.put("byte", byte.class);
specialClasses.put("char", char.class);
specialClasses.put("short", short.class);
specialClasses.put("int", int.class);
specialClasses.put("long", long.class);
specialClasses.put("float", float.class);
specialClasses.put("double", double.class);
specialClasses.put("void", void.class);
}
private static final DownloadPermission[] perm = {new
DownloadPermission()};
private static List<String> dynamicGrants = new ArrayList<String>();
/**
* value to pass as the "default loader" argument to loadClass and
* loadProxyClass
**/
private final ClassLoader defaultLoader;
/** true if this stream verifies codebase integrity */
private final boolean verifyCodebaseIntegrity;
/** loader to pass to Security.verifyCodebaseIntegrity */
private final ClassLoader verifierLoader;
/**
* if false, pass null codebase values to loadClass and
* loadProxyClass methods; if true, pass codebase values from
* stream class annotations
**/
private boolean usingCodebaseAnnotations;
private final ProxyPreparer preparer;
/**
* Creates a new <code>AuthMarshalInputStream</code> that reads
* marshalled data from the specified underlying
* <code>InputStream</code>.
*
* <p>This constructor passes <code>in</code> to the superclass
* constructor that has an <code>InputStream</code> parameter.
*
* <p><code>defaultLoader</code> will be passed as the
* <code>defaultLoader</code> argument to {@link
* ClassLoading#loadClass ClassLoading.loadClass} and {@link
* ClassLoading#loadProxyClass ClassLoading.loadProxyClass}
* whenever those methods are invoked by {@link #resolveClass
* resolveClass} and {@link #resolveProxyClass resolveProxyClass}.
*
* <p>If <code>verifyCodebaseIntegrity</code> is
* <code>true</code>, then the created stream will verify that all
* codebase annotation URLs that are used to load classes resolved
* by the stream provide content integrity, and whenever {@link
* Security#verifyCodebaseIntegrity
* Security.verifyCodebaseIntegrity} is invoked to enforce that
* verification, <code>verifierLoader</code> will be passed as the
* <code>loader</code> argument. See {@link
* ClassLoading#loadClass ClassLoading.loadClass} and {@link
* ClassLoading#loadProxyClass ClassLoading.loadProxyClass} for
* details of how codebase integrity verification is performed.
*
* <p><code>context</code> will be used as the return value of the
* created stream's {@link #getObjectStreamContext
* getObjectStreamContext} method.
*
* @param in the input stream to read marshalled data from
*
* @param defaultLoader the class loader value (possibly
* <code>null</code>) to pass as the <code>defaultLoader</code>
* argument to <code>ClassLoading</code> methods
*
* @param verifyCodebaseIntegrity if <code>true</code>, this
* stream will verify that codebase annotation URLs used to load
* classes resolved by this stream provide content integrity
*
* @param verifierLoader the class loader value (possibly
* <code>null</code>) to pass to
* <code>Security.verifyCodebaseIntegrity</code>, if
* <code>verifyCodebaseIntegrity</code> is <code>true</code>
*
* @param context the collection of context information objects to
* be returned by this stream's {@link #getObjectStreamContext
* getObjectStreamContext} method
*
* @param preparer the proxy preparer used to authenticate the server
* prior to downloading any classes.
*
* @throws IOException if the superclass's constructor throws an
* <code>IOException</code>
*
* @throws SecurityException if the superclass's constructor
* throws a <code>SecurityException</code>
*
* @throws NullPointerException if <code>in</code> or
* <code>context</code> is <code>null</code>
**/
public AuthMarshalInputStream(InputStream in,
ClassLoader defaultLoader,
boolean verifyCodebaseIntegrity,
ClassLoader verifierLoader,
Collection context,
ProxyPreparer preparer )
throws IOException
{
super (in, defaultLoader, verifyCodebaseIntegrity, verifierLoader,
context);
this.defaultLoader = defaultLoader;
this.verifyCodebaseIntegrity = verifyCodebaseIntegrity;
this.verifierLoader = verifierLoader;
this.preparer = preparer;
}
// Inherit documentation from MarshalInputStream
@Override
public void useCodebaseAnnotations() {
usingCodebaseAnnotations = true;
super.useCodebaseAnnotations();
}
// Inherit documentation from MarshalInputStream
@Override
protected Class resolveClass(ObjectStreamClass classDesc)
throws IOException, ClassNotFoundException
{
if (classDesc == null) {
throw new NullPointerException();
}
// must always consume annotation written by MarshalOutputStream
String annotation = readAnnotation();
String codebase = usingCodebaseAnnotations ? annotation : null;
authenticate(codebase);
String name = classDesc.getName();
try {
return ClassLoading.loadClass(codebase,
name,
defaultLoader,
verifyCodebaseIntegrity,
verifierLoader);
} catch (ClassNotFoundException e) {
Class c = specialClasses.get(name);
if (c != null) {
return c;
} else {
throw e;
}
}
}
// Inherit documentation from MarshalInputStream
@Override
protected Class resolveProxyClass(String[] interfaceNames)
throws IOException, ClassNotFoundException
{
for (int i = 0; i < interfaceNames.length; i++) {
if (interfaceNames[i] == null) {
throw new NullPointerException();
}
}
// must always consume annotation written by MarshalOutputStream
String annotation = readAnnotation();
String codebase = usingCodebaseAnnotations ? annotation : null;
authenticate(codebase);
return ClassLoading.loadProxyClass(codebase,
interfaceNames,
defaultLoader,
verifyCodebaseIntegrity,
verifierLoader);
}
private void authenticate(String codebase)
throws IOException, ClassNotFoundException{
// Always read the proxy from the AuthMarshalInputStream
Object proxy = readObject();
if (codebase == null) return;
if (dynamicGrants.contains(codebase)) return;
try {
//Authenticate
preparer.prepareProxy(proxy);
// Dynamically Grant DownloadPermission for each URL via a
// CodeSource grant.
Policy policy = Policy.getPolicy();
if (policy instanceof RevokeableDynamicPolicy){
StringTokenizer st = new StringTokenizer(codebase); // divide by
spaces
URL[] urls = new URL[st.countTokens()];
for (int i = 0; st.hasMoreTokens(); i++) {
urls[i] = new URL(st.nextToken());
}
PermissionGrantBuilder pgb
= ((RevokeableDynamicPolicy) policy).getGrantBuilder();
pgb.permissions(perm);
int l = urls.length;
List<PermissionGrant> grants = new ArrayList<PermissionGrant>(l);
for (int i = 0; i < l; i++){
CodeSource cs = new CodeSource(urls[i], (Certificate[]) null);
PermissionGrant pg = pgb.codeSource(cs).build();
grants.add(pg);
}
((RevokeableDynamicPolicy) policy).grant(grants);
}
dynamicGrants.add(codebase);
} catch (SecurityException e) {
throw new IOException(e);
} catch (MalformedURLException e){
throw new IOException(e);
}
}
}
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Michal Kleczek wrote:
>> On Tuesday 12 of October 2010 00:27:12 Peter Firmstone wrote:
>>
>>> Michal Kleczek wrote:
>>>
>>>> On Monday 11 of October 2010 15:41:46 Peter Firmstone wrote:
>>>>
>>>>> What about the case where a Module depends on another Module?
>>>>>
>>>>> I'm guessing that was the intent.
>>>>>
>>>> Actually - no :)
>>>>
>>>> There are two different things to consider:
>>>>
>>>> 1. Module dependencies (which I actually did not think about too
>>>> much).
>>>>
>>> Actually I'm thinking there shouldn't be any dependencies, other than
>>> the Jini Platform and ServiceAPI, which has been used to obtain the
>>> Module.
>>
>> This is true as long as we have one special ClassLoader that loads
>> ServiceAPIs. That is the case with current Jini and has its
>> ramifications.
>>
>> Once you think about peer class loading model where different
>> versions of the same class (even ServiceAPI class) can coexist you
>> need Module dependencies.
>>
>> But let's not go there at this moment.
>>
>> I don't think there are many differences between our ideas - let me
>> summarize them (at least how I understand them).
>>
>> 1. You want to issue a remote call to _retrieve_ annotations whereas
>> I want to do that to _verify_ them.
>>
>
> Yes, but only after the annotated reflective proxy which is an
> instance of ProxyTrust and RemoteMethodControl, has been verified. It
> can be deserialized simply because it resolves to local classes.
>
>> I think this is a problem since this way you cannot turn this stuff
>> off altogether (for example for testing).
>>
>> 2. You want to automatically grant DownloadPermission to CodeSources
>> you've just retrieved
>>
>
> No, just a small misunderstanding, a CodeSource, is a URL and some
> signer Certificates, it's the opposite way around, I want to know the
> CodeSource I'm going to grant DownloadPermission to, so the jar file
> referenced by the URL in the CodeSource can be downloaded. If I don't
> grant DownloadPermission to the CodeSource, it can't be downloaded, at
> least that's how PreferredClassLoader works.
>
> I can also check if I trust the signers and if the URL supports
> integrity constraints.
>
> Remember this is after authenticating the proxy.
>
>> I think that is a problem since it means suppressing standard
>> DownloadPermission checks altogether. I would say - just use standard
>> PreferredClassProvider that does not do DownloadPermission checks.
>>
>> 3. You want to automatically grant GrantPermission(new
>> DownloadPermission()) to new ClassLoaders
>>
>
> Well not quite ClassLoaders, to CodeSources, in order to make them
> downloadable, but it might be pushing the trust boundary too far.
>
>> And that is something I would like to be conditional - the client has
>> to have a way to either allow or not allow a proxy to download more
>> code without local verification. But it must be possible to say:
>> "I've got a proxy from you and I trust you verified the code you are
>> going to download to my address space - so I won't check this code by
>> myself"
>>
>>
>
> I think your idea to annotate using an object that has only local code
> and can be verified is pure Genius ;) I never would have thought of
> that, you're definitely thinking outside the box.
>
> However I'm wondering if a service is asking for too much client trust
> to give a ClassLoader reference to a Module, obtained from a third
> party ModuleAuthority.
>
> I think we can take advantage of your idea to annotate an Object that
> can be deserialized, it's class resolved using only local code.
>
> That Object could be a Service that uses a java.lang.reflect.Proxy
> only (smart proxy cannot be deserialized without code) Said Service
> is not registered with any registrar, it is just an Exported Object
> that implements ProxyTrust and RemoteMethodControl as well as an
> interface to obtain the CodeSources.
>
> Perhaps the annotation should just be a proxy that we can ask for the
> CodeSources after it has been validated and authenticated.
>
> We could simply have a CodeSourceExporter, which implements ProxyTrust
> and RemoteMethodControl, this could be automatically generated from
> local CodeSource information, or provided by the service
> specifically. The CodeSource[] would be that required by the smart
> proxy.
>
> interface CodeSourceExporter {
> CodeSource[] getCodebase(Class[] urlStreamHandlerClasses) throws
> IOException;
> long getCodebaseSize() throws IOException;
> }
This would be better:
interface CodeSouceExporter {
CodeSource[] getCodebase(String[] urlStreamHandlerClassNames) throws
IOException;
long getCodebaseSize() throws IOException;
}
>
> We could simplify this to:
>
> 1. Annotate ObjectOutputStream's with a java.lang.reflect.Proxy that
> must implement ProxyTrust, RemoteMethodControl and
> CodeSourceExporter
> 2. Then during unmarshalling, deserialize, verify and authenticate
> the proxy.
> 3. Obtain the CodeSource's, the URL will be in the first matching
> available URL format from the array of URLStreamHandler Class files.
> 4. Grant the CodeSource's DownloadPermission, because we trust the
> Proxy.
> 5. Use Gregg's CodebaseAccessClassLoader to load the smart proxy
> class files.
> 6. Unmarshall the smart proxy, verify autenticate, add constraints etc.
>
> We could also extend CodeSource to contain the Subject (or some unique
> identifier?) of the Service, with CodeSourceExporter, to ensure that
> ClassLoaders only load classes from one Service (Different Services
> sharing classes poses a security risk), in case distinct services
> share common URL's. (The Subject would be a private field in the
> CodeSource, used only for hashCode and equals comparisons).
>
> Then we could add a method to Gregg's CodebaseAccessClassLoader to
> load classes using CodeSource[] rather than a URL String.
>
> We could have a Caching URLHandler as per Sim's suggestion (and as
> Gregg has done for years!), so we could have our cake and eat it too.
>
> Gregg's CodebaseAccessClassLoader has been successfully used with OSGi.
>
> Thoughts?
>
> Cheers,
>
> Peter.
>
>
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Michal Kleczek wrote:
> On Tuesday 12 of October 2010 00:27:12 Peter Firmstone wrote:
>
>> Michal Kleczek wrote:
>>
>>> On Monday 11 of October 2010 15:41:46 Peter Firmstone wrote:
>>>
>>>> What about the case where a Module depends on another Module?
>>>>
>>>> I'm guessing that was the intent.
>>>>
>>> Actually - no :)
>>>
>>> There are two different things to consider:
>>>
>>> 1. Module dependencies (which I actually did not think about too much).
>>>
>> Actually I'm thinking there shouldn't be any dependencies, other than
>> the Jini Platform and ServiceAPI, which has been used to obtain the
>> Module.
>>
>
> This is true as long as we have one special ClassLoader that loads
> ServiceAPIs. That is the case with current Jini and has its ramifications.
>
> Once you think about peer class loading model where different versions of the
> same class (even ServiceAPI class) can coexist you need Module dependencies.
>
> But let's not go there at this moment.
>
> I don't think there are many differences between our ideas - let me summarize
> them (at least how I understand them).
>
> 1. You want to issue a remote call to _retrieve_ annotations whereas I want to
> do that to _verify_ them.
>
Yes, but only after the annotated reflective proxy which is an instance
of ProxyTrust and RemoteMethodControl, has been verified. It can be
deserialized simply because it resolves to local classes.
> I think this is a problem since this way you cannot turn this stuff off
> altogether (for example for testing).
>
> 2. You want to automatically grant DownloadPermission to CodeSources you've
> just retrieved
>
No, just a small misunderstanding, a CodeSource, is a URL and some
signer Certificates, it's the opposite way around, I want to know the
CodeSource I'm going to grant DownloadPermission to, so the jar file
referenced by the URL in the CodeSource can be downloaded. If I don't
grant DownloadPermission to the CodeSource, it can't be downloaded, at
least that's how PreferredClassLoader works.
I can also check if I trust the signers and if the URL supports
integrity constraints.
Remember this is after authenticating the proxy.
> I think that is a problem since it means suppressing standard
> DownloadPermission checks altogether. I would say - just use standard
> PreferredClassProvider that does not do DownloadPermission checks.
>
> 3. You want to automatically grant GrantPermission(new DownloadPermission())
> to new ClassLoaders
>
Well not quite ClassLoaders, to CodeSources, in order to make them
downloadable, but it might be pushing the trust boundary too far.
> And that is something I would like to be conditional - the client has to have
> a way to either allow or not allow a proxy to download more code without local
> verification. But it must be possible to say: "I've got a proxy from you and I
> trust you verified the code you are going to download to my address space - so
> I won't check this code by myself"
>
>
I think your idea to annotate using an object that has only local code
and can be verified is pure Genius ;) I never would have thought of
that, you're definitely thinking outside the box.
However I'm wondering if a service is asking for too much client trust
to give a ClassLoader reference to a Module, obtained from a third party
ModuleAuthority.
I think we can take advantage of your idea to annotate an Object that
can be deserialized, it's class resolved using only local code.
That Object could be a Service that uses a java.lang.reflect.Proxy only
(smart proxy cannot be deserialized without code) Said Service is not
registered with any registrar, it is just an Exported Object that
implements ProxyTrust and RemoteMethodControl as well as an interface to
obtain the CodeSources.
Perhaps the annotation should just be a proxy that we can ask for the
CodeSources after it has been validated and authenticated.
We could simply have a CodeSourceExporter, which implements ProxyTrust
and RemoteMethodControl, this could be automatically generated from
local CodeSource information, or provided by the service specifically.
The CodeSource[] would be that required by the smart proxy.
interface CodeSourceExporter {
CodeSource[] getCodebase(Class[] urlStreamHandlerClasses) throws
IOException;
long getCodebaseSize() throws IOException;
}
We could simplify this to:
1. Annotate ObjectOutputStream's with a java.lang.reflect.Proxy that
must implement ProxyTrust, RemoteMethodControl and CodeSourceExporter
2. Then during unmarshalling, deserialize, verify and authenticate
the proxy.
3. Obtain the CodeSource's, the URL will be in the first matching
available URL format from the array of URLStreamHandler Class files.
4. Grant the CodeSource's DownloadPermission, because we trust the Proxy.
5. Use Gregg's CodebaseAccessClassLoader to load the smart proxy
class files.
6. Unmarshall the smart proxy, verify autenticate, add constraints etc.
We could also extend CodeSource to contain the Subject (or some unique
identifier?) of the Service, with CodeSourceExporter, to ensure that
ClassLoaders only load classes from one Service (Different Services
sharing classes poses a security risk), in case distinct services share
common URL's. (The Subject would be a private field in the CodeSource,
used only for hashCode and equals comparisons).
Then we could add a method to Gregg's CodebaseAccessClassLoader to load
classes using CodeSource[] rather than a URL String.
We could have a Caching URLHandler as per Sim's suggestion (and as Gregg
has done for years!), so we could have our cake and eat it too.
Gregg's CodebaseAccessClassLoader has been successfully used with OSGi.
Thoughts?
Cheers,
Peter.
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 12 of October 2010 00:27:12 Peter Firmstone wrote:
> Michal Kleczek wrote:
> > On Monday 11 of October 2010 15:41:46 Peter Firmstone wrote:
> >> What about the case where a Module depends on another Module?
> >>
> >> I'm guessing that was the intent.
> >
> > Actually - no :)
> >
> > There are two different things to consider:
> >
> > 1. Module dependencies (which I actually did not think about too much).
>
> Actually I'm thinking there shouldn't be any dependencies, other than
> the Jini Platform and ServiceAPI, which has been used to obtain the
> Module.
This is true as long as we have one special ClassLoader that loads
ServiceAPIs. That is the case with current Jini and has its ramifications.
Once you think about peer class loading model where different versions of the
same class (even ServiceAPI class) can coexist you need Module dependencies.
But let's not go there at this moment.
I don't think there are many differences between our ideas - let me summarize
them (at least how I understand them).
1. You want to issue a remote call to _retrieve_ annotations whereas I want to
do that to _verify_ them.
I think this is a problem since this way you cannot turn this stuff off
altogether (for example for testing).
2. You want to automatically grant DownloadPermission to CodeSources you've
just retrieved
I think that is a problem since it means suppressing standard
DownloadPermission checks altogether. I would say - just use standard
PreferredClassProvider that does not do DownloadPermission checks.
3. You want to automatically grant GrantPermission(new DownloadPermission())
to new ClassLoaders
And that is something I would like to be conditional - the client has to have
a way to either allow or not allow a proxy to download more code without local
verification. But it must be possible to say: "I've got a proxy from you and I
trust you verified the code you are going to download to my address space - so
I won't check this code by myself"
Michal
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Michal Kleczek wrote:
> On Monday 11 of October 2010 15:41:46 Peter Firmstone wrote:
>
>> What about the case where a Module depends on another Module?
>>
>> I'm guessing that was the intent.
>>
>>
>
> Actually - no :)
>
> There are two different things to consider:
>
> 1. Module dependencies (which I actually did not think about too much).
>
Actually I'm thinking there shouldn't be any dependencies, other than
the Jini Platform and ServiceAPI, which has been used to obtain the
Module. In fact the Module is a handler for the Proxy Namespace
(sandbox), the ClassLoader returned by getClassLoader(Subject s) will
know which ClassLoader is used within the proxy namespace, if there is
more than one ClassLoader for that Subject.
We could rename Module to ProxyNamespace?
> and
> 2. The client gets a proxy and this proxy code causes downloading objects
> annotated with a different Module than the proxy's Module (IOW downloading
> subsequent Modules happens _after_ the proxy was deserialized, prepared and
> granted permissions). We need a way to say:
> "OK I've downloaded some code, an object, verified that I trust both the code
> and this object - now I don't really care how it is implemented - I trust that
> if it needs to download some more code - it already was verified)."
>
Actually we don't need to do that if the annotation is a reflective
proxy, since it is deserialized using only local code.
> That is something that can be achieved with DelegatedModuleTrustVerifier - the
> client can grant DownloadPermission to the proxy it just deserialized and
> prepared. Note that it is not transitive - the client has to grant a
> GrantPermission(new DownloadPermission()) to the proxy if it wants the
> DownloadPermission to be transfered further.
>
If the annotation is a reflective proxy, namely ModuleServiceProvider,
we verify it, get the CodeSource, for the Module from it, using only
local code, at this point in time the Module proxy doesn't exist, we
grant DownloadPermission to the CodeSource (it's jar file hasn't yet
been downloaded). This only permits download of the jar file.
Then we ask the ModuleServiceProvider for the Module Object and
deserialize it using a ClassLoader we just created.
We then verify the Module and grant it GrantPermission(DownloadPermission).
The Module can now download any CodeSource's required by our service
proxy, which has yet to be unmarshalled, the Module has to grant
DownloadPermission to each CodeSource it wants to download. Remember
the proxy doesn't know it's CodeSource, the Module does. We trust the
Module not to abuse the trust we have just granted.
If the service proxy returns another service proxy, it will be annotated
with it's own ModuleServiceProvider and the whole process repeats.
The Module is the package handler the Service gets to dynamically inject
into the client to organise it's proxy namespace.
> All is good so far except that the proxy must postpone deserialization of
> subsequent objects so that it happens after the client had a chance to grant
> permissions to the proxy.
> With my proposal nothing really changes in a way the client handles objects
> that it receives - permissions are granted to the proxy in exactly the same
> way as it is done in Jini 2.1.
>
> So unfortunatelly if we have a proxy:
> class MyProxy implements Serializable {
> private JavaSpace space;
> //
> }
> it would have to be changed to:
> class MyProxy implements Serializable {
> private MarshalledObject<JavaSpace> marshalledSpace;
> }
> if the service wants to make use of DownloadPermission that was possibly
> granted to it by the client.
>
> Sure - it would be cool if we could grant permissions earlier (as soon as a
> Module is verified and the ClassLoader is created) but I just don't know how
> the client would pass the permissions it wants to grant to a Module to the low
> level deserialization code.
>
We only grant DownloadPermission, to each CodeSource, the proxy will
inherit the DownloadPermission from it's CodeSource, but it can't use it
to go and download another CodeSource. The proxy doesn't yet exist, when
we grant the DownloadPermission. We delay all other Permission's granted
to the proxy until it is verified, when the permissions can be directly
negotiated between the proxy and client.
This process will be the same, no matter what the service proxy being
unmarshalled is.
> Michal
>
>
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Monday 11 of October 2010 15:41:46 Peter Firmstone wrote:
> What about the case where a Module depends on another Module?
>
> I'm guessing that was the intent.
>
Actually - no :)
There are two different things to consider:
1. Module dependencies (which I actually did not think about too much).
and
2. The client gets a proxy and this proxy code causes downloading objects
annotated with a different Module than the proxy's Module (IOW downloading
subsequent Modules happens _after_ the proxy was deserialized, prepared and
granted permissions). We need a way to say:
"OK I've downloaded some code, an object, verified that I trust both the code
and this object - now I don't really care how it is implemented - I trust that
if it needs to download some more code - it already was verified)."
That is something that can be achieved with DelegatedModuleTrustVerifier - the
client can grant DownloadPermission to the proxy it just deserialized and
prepared. Note that it is not transitive - the client has to grant a
GrantPermission(new DownloadPermission()) to the proxy if it wants the
DownloadPermission to be transfered further.
All is good so far except that the proxy must postpone deserialization of
subsequent objects so that it happens after the client had a chance to grant
permissions to the proxy.
With my proposal nothing really changes in a way the client handles objects
that it receives - permissions are granted to the proxy in exactly the same
way as it is done in Jini 2.1.
So unfortunatelly if we have a proxy:
class MyProxy implements Serializable {
private JavaSpace space;
//
}
it would have to be changed to:
class MyProxy implements Serializable {
private MarshalledObject<JavaSpace> marshalledSpace;
}
if the service wants to make use of DownloadPermission that was possibly
granted to it by the client.
Sure - it would be cool if we could grant permissions earlier (as soon as a
Module is verified and the ClassLoader is created) but I just don't know how
the client would pass the permissions it wants to grant to a Module to the low
level deserialization code.
Michal
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
What about the case where a Module depends on another Module?
I'm guessing that was the intent.
Regards,
Peter.
Peter Firmstone wrote:
> Edited slightly note: <edit-remove>for the Subject</edit-remove>
>
> Peter Firmstone wrote:
>> Ok,
>>
>> The ModuleServiceProvider adds a step:
>>
>> 1. A ModuleServiceProvider is deserialized (reflective proxy only)
>> (consider it a Module Factory, could rename it to that too).
>> 2. Deserialized ModuleServiceProvider is verified
>> 3. A Module cache is checked using the ModuleServiceProvider as a key
>> (weakly referenced).
>> 4. If a Module exists in the cache, then that is used instead, goto 6.
>> 5. If a Module doesn't exist in the cache <edit-remove>for the
>> Subject</edit-remove> a new
>> Module will be created using the ModuleServiceProvider
>> 1. CodeSource[] is obtained for the Module using the
>> ModuleServiceProvider
>> 2. DownloadPermission is dynamically granted to all CodeSource
>> in the array CodeSource[] only.
>> 3. DownloadPermission is only required to load the jar files
>> for the Module, via overriding
>> SecureClassLoader.getPermissions(CodeSource cs) as per
>> PreferredClassLoader.
>> 4. The Module is deserialized, using the CodeSource[] URL's in
>> a new ClassLoader instance.
>> 5. The Module is verified.
>> 6. The Module is granted GrantPermission(DownloadPermission)
>> 7. The Module knows which CodeSources require
>> DownloadPermission and grant's these dynamically on an as
>> needed basis.
>> 8. The Module needs a guard to check the caller has sufficient
>> permission to use it, this would be created during module
>> construction, we need to define a standard guard permissions
>> for each method.
>> 9. The Module is stored in the cache associated with the
>> ModuleServiceProvider.
>> 6. The Service Proxy is unmarshalled.
>> 7. The service is verified (it has to authenticate with the same
>> Subject as the ModuleServiceProvider).
>> 8. The service is used. (Constraints ensure the service authenticates
>> every method invocation).
>>
>> Note: The ModuleServiceProvider has the same Subject as the Service
>> Proxy.
>>
>> Module needs an additional method:
>>
>> ClassLoader getClassLoader(Subject s);
>>
>> The Module needs to have a Subject parameter added to it's other
>> methods too, the Module already know's the Codebase URL's, since this
>> is it's responsibility, however it needs to ensure that different
>> Subject's don't share ClassLoaders, in case multiple Subjects are
>> using one Module with identical CodeSource, in the case where the
>> Module Service provides for a number of Subjects.
>>
>> The Module Service, knows which jar files, module / package versions
>> are in use for the requested classes.
>>
>> If Service Proxy's had OSGi embedded, they could be shutdown and
>> reloaded with new Module versions, this would be synchronous with the
>> Module Service.
>>
>> Ordinary services might simply be stopped and re looked up with
>> updated jar files and annotated with a new ModuleServiceProvider
>> instance.
>>
>> We can choose to limit other permission's also like
>> SocketPermission's to particular domains.
>>
>> Can we cache jar files somehow based on their URL?
>>
>> I'm not certain if this is right, what do you think?
>>
>> Cheers,
>>
>> Peter.
>>
>>
>> Michal Kleczek wrote:
>>> Thanks for the tips on using Guard and subclassing Permission - I
>>> will update the code.
>>>
>>> But I am not completely sure I follow your idea of
>>> ModuleServiceProvider.
>>>
>>> I'll try to explain why I think two permissions are needed.
>>> Let's imagine a simple scenario:
>>>
>>> 1. A client gets a service proxy.
>>> 2. Before actually downloading any code and deserializing the proxy
>>> the client wants to verify a Module that it received as annotation.
>>> 3. After the proxy is deserialized the client wants to grant the
>>> proxy a permission to deserialize other objects that possibly will
>>> require other Modules to be downloaded.
>>>
>>> So the following steps are performed:
>>> 1. A Module is deserialized
>>> 2. Deserialized Module is verified
>>> 3. A service proxy is deserialized
>>> 4. The service proxy is verified
>>> 5. DownloadPermission is granted to the proxy ClassLoader (note that
>>> it is a different ClassLoader than Module's ClassLoader)
>>>
>>> But how can we implement conditional Module verification?
>>> We can have a locally installed verifier that just checks if
>>> currently executing code has DownloadPermission and if that's the
>>> case consider any Module trusted. But - of course - the client
>>> itself has DownloadPermission, so this verifier would cause
>>> suppressing of Module verification alltogether.
>>> The idea is to have another permission that only the client has -
>>> the verifier would check that permission and if the calling code has
>>> it - consider Modules untrusted.
>>> So now the sequence is as follows:
>>> 1. A Module is deserialized
>>> 2. DelegatedModuleTrustVerifier checks for
>>> SuppressModuleInstallPermission.
>>> 3. The client has it so DelegatedModuleTrustVerifier returns false
>>> 4. The Module is verified using standard ProxyTrustVerifier
>>> 5. A proxy is deserialized
>>> 6. The proxy is verified
>>> 7. The proxy is granted DownloadPermission
>>> 8. The proxy tries to deserialize a subsequent object (annotated
>>> with another Module)
>>> 9. A Module is desecialized
>>> 10. DelegatedModuleTrustVerifier checks for
>>> SuppressModuleInstallPermission. Calling code does not have it so
>>> DelegatedModuleTrustVerifier checks for DownloadPermission. Calling
>>> code does have DownloadPermission (see p. 7) so we consider this
>>> Module trusted
>>> 11. We're done :)
>>>
>>> Michal
>>>
>>>
>>> On Monday 11 of October 2010 13:06:18 Peter Firmstone wrote:
>>>
>>>> I don't completely follow, why do you need the additional permission?
>>>>
>>>> Perhaps we could have ModuleServiceProvider that only allows a
>>>> reflective proxy? We can authenticate a reflective proxy because
>>>> there's no downloaded code.
>>>>
>>>> interface ModuleServiceProvider {
>>>> CodeSource[] getModuleCodeSources();
>>>> Module getModule();
>>>> }
>>>>
>>>> Setting up the Module from the ModuleServiceProvider, we can obtain
>>>> the
>>>> CodeSource URL and Certificate's before downloading any jar files for
>>>> the module and check if a Module ClassLoader has been registered
>>>> for the
>>>> Subject.
>>>>
>>>> We can then dynamically grant Permissions to that ClassLoader
>>>> (using the
>>>> Module's class) with the Subject's Principals[], so it only has the
>>>> necessary Permission's when run as the Subject of the Service.
>>>>
>>>> A marshalled smart proxy could be annotated with the
>>>> ModuleServiceProvider, which is authenticated, and has constraints
>>>> set,
>>>> prior to instantiating a ClassLoader with the URL[]'s(if it doesn't
>>>> already exist), then deserialize the Module into it (by setting the
>>>> context ClassLoader) and use the new Module to provision the smart
>>>> proxy's jar archives.
>>>>
>>>> Have a look at Gregg Wonderly's CodebaseAccessClassLoader too.
>>>>
>>>> http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/src/net/jini/loader
>>>>
>>>> /?pathrev=934258
>>>>
>>>> Some Permission Tips:
>>>>
>>>> 1. For simple Permission classes, extend Permission instead of
>>>> BasicPermission if you can, if you don't need implement your own
>>>> PermissionCollection, the Policy will provide an implementation
>>>> for you (I provide a multi read PermissionCollection with my
>>>> Policy Provider for better concurrency).
>>>> 2. Try using Guard installModule = new InstallModulePermission();
>>>> Then instead of calling the AccessController or SecurityManager,
>>>> call installModule.checkGuard() instead, it gets the security
>>>> manager for you and checks the Permission, when I've got the
>>>> InternetSecurityManager finished, this will speed up your
>>>> permission check for repeated checks.
>>>>
>>>> try {
>>>> installModule.checkGuard(this);
>>>> return true;
>>>> } catch (SecurityException ex) {
>>>> return false;
>>>> }
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>
>>>> Michal Kleczek wrote:
>>>>
>>>>> Of course we need something more since the client has
>>>>> InstallModulePermission it would suppress trust verification
>>>>> alltogether. The simple fix is to have two permissions and suppress
>>>>> trust verification only when we only have one of them. The client has
>>>>> both, so we are going to verify trust.
>>>>>
>>>>> class InstallModulePermission extends BasicPermission {
>>>>> }
>>>>>
>>>>> class SuppressInstallModulePermission extends BasicPermission {
>>>>> }
>>>>>
>>>>> public class DelegatedModuleTrustVerifier implements TrustVerifier {
>>>>>
>>>>> private static final InstallModulePermission
>>>>> INSTALL_MODULE_PERMISSION =
>>>>> new InstallModulePermission();
>>>>> private static final SuppressModuleTrustDelegationPermission
>>>>> SUPPRESS_MODULE_TRUST_DELEGATION_PERMISSION =
>>>>> new SuppressModuleTrustDelegationPermission();
>>>>> @Override
>>>>> public boolean isTrustedObject(Object o, Context cntxt) {
>>>>> if (o instanceof Module) {
>>>>> try {
>>>>>
>>>>> AccessController.checkPermission(SUPPRESS_MODULE_TRUST_DE
>>>>> LEGATION_PERMISSION); return false;
>>>>> }
>>>>> catch (SecurityException suppressEx) {
>>>>> try {
>>>>>
>>>>> AccessController.checkPermission(INSTALL_MODULE_PERMI
>>>>> SSION); return true;
>>>>> }
>>>>> catch (SecurityException installEx) {
>>>>> return false;
>>>>> }
>>>>> }
>>>>> }
>>>>> return false;
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> Michal
>>>>>
>>>>> On Monday 11 of October 2010 08:24:19 Michal Kleczek wrote:
>>>>>
>>>>>> On Monday 11 of October 2010 05:27:31 Peter Firmstone wrote:
>>>>>>
>>>>>>> Michal Kleczek wrote:
>>>>>>>
>>>>>>>> Some more thoughts.
>>>>>>>>
>>>>>>>> There is one scenario that is not covered here:
>>>>>>>>
>>>>>>>> I get an service, verify the module that loads its class using a
>>>>>>>> ModuleAuthority that I trust. This service in turn downloads some
>>>>>>>> other objects that it verified. There is no way I can delegate
>>>>>>>> trust
>>>>>>>> verification to the service - I must trust Modules (actually
>>>>>>>> ModuleAuthorities) of those subsequent objects.
>>>>>>>>
>>>>>>>> 1. I have to have a way to allow or disallow module trust
>>>>>>>> delegation
>>>>>>>> (looks like a case for dynamic permission grants)
>>>>>>>>
>>>>>>> Currently PreferredClassLoader uses DownloadPermission to
>>>>>>> prevent or
>>>>>>> allow a CodeSource class loading, because the CodeSource hasn't yet
>>>>>>> been loaded, we cannot dynamically grant DownloadPermission to a
>>>>>>> CodeSource, using DynamicPolicy.
>>>>>>>
>>>>>> Thanks for the hint.
>>>>>> I think Module trust delegation can be achieved in a really
>>>>>> simple way:
>>>>>>
>>>>>> class InstallModulePermission extends Permission {
>>>>>> }
>>>>>>
>>>>>> //this TrustVerifier is installed locally on the client
>>>>>> //so that delegation of Module trust verification can be done
>>>>>> //by granting a service InstallModulePermission
>>>>>>
>>>>>> public class InstallModulePermissionVerifier implements
>>>>>> TrustVerifier {
>>>>>>
>>>>>> private static final InstallModulePermission PERM =
>>>>>> new InstallModulePermission()
>>>>>> public boolean isTrustedObject(Object o, Context ctx) {
>>>>>> try {
>>>>>> if (o instanceof Module) {
>>>>>> AccessController.checkPermission(PERM);
>>>>>> return true;
>>>>>> }
>>>>>> return false;
>>>>>> }
>>>>>> catch (SecurityException e) {
>>>>>> return false;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Michal
>>>>>>
>>>
>>>
>>
>>
>
>
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Edited slightly note: <edit-remove>for the Subject</edit-remove>
Peter Firmstone wrote:
> Ok,
>
> The ModuleServiceProvider adds a step:
>
> 1. A ModuleServiceProvider is deserialized (reflective proxy only)
> (consider it a Module Factory, could rename it to that too).
> 2. Deserialized ModuleServiceProvider is verified
> 3. A Module cache is checked using the ModuleServiceProvider as a key
> (weakly referenced).
> 4. If a Module exists in the cache, then that is used instead, goto 6.
> 5. If a Module doesn't exist in the cache <edit-remove>for the
> Subject</edit-remove> a new
> Module will be created using the ModuleServiceProvider
> 1. CodeSource[] is obtained for the Module using the
> ModuleServiceProvider
> 2. DownloadPermission is dynamically granted to all CodeSource
> in the array CodeSource[] only.
> 3. DownloadPermission is only required to load the jar files
> for the Module, via overriding
> SecureClassLoader.getPermissions(CodeSource cs) as per
> PreferredClassLoader.
> 4. The Module is deserialized, using the CodeSource[] URL's in
> a new ClassLoader instance.
> 5. The Module is verified.
> 6. The Module is granted GrantPermission(DownloadPermission)
> 7. The Module knows which CodeSources require
> DownloadPermission and grant's these dynamically on an as
> needed basis.
> 8. The Module needs a guard to check the caller has sufficient
> permission to use it, this would be created during module
> construction, we need to define a standard guard permissions
> for each method.
> 9. The Module is stored in the cache associated with the
> ModuleServiceProvider.
> 6. The Service Proxy is unmarshalled.
> 7. The service is verified (it has to authenticate with the same
> Subject as the ModuleServiceProvider).
> 8. The service is used. (Constraints ensure the service authenticates
> every method invocation).
>
> Note: The ModuleServiceProvider has the same Subject as the Service
> Proxy.
>
> Module needs an additional method:
>
> ClassLoader getClassLoader(Subject s);
>
> The Module needs to have a Subject parameter added to it's other
> methods too, the Module already know's the Codebase URL's, since this
> is it's responsibility, however it needs to ensure that different
> Subject's don't share ClassLoaders, in case multiple Subjects are
> using one Module with identical CodeSource, in the case where the
> Module Service provides for a number of Subjects.
>
> The Module Service, knows which jar files, module / package versions
> are in use for the requested classes.
>
> If Service Proxy's had OSGi embedded, they could be shutdown and
> reloaded with new Module versions, this would be synchronous with the
> Module Service.
>
> Ordinary services might simply be stopped and re looked up with
> updated jar files and annotated with a new ModuleServiceProvider
> instance.
>
> We can choose to limit other permission's also like SocketPermission's
> to particular domains.
>
> Can we cache jar files somehow based on their URL?
>
> I'm not certain if this is right, what do you think?
>
> Cheers,
>
> Peter.
>
>
> Michal Kleczek wrote:
>> Thanks for the tips on using Guard and subclassing Permission - I
>> will update the code.
>>
>> But I am not completely sure I follow your idea of
>> ModuleServiceProvider.
>>
>> I'll try to explain why I think two permissions are needed.
>> Let's imagine a simple scenario:
>>
>> 1. A client gets a service proxy.
>> 2. Before actually downloading any code and deserializing the proxy
>> the client wants to verify a Module that it received as annotation.
>> 3. After the proxy is deserialized the client wants to grant the
>> proxy a permission to deserialize other objects that possibly will
>> require other Modules to be downloaded.
>>
>> So the following steps are performed:
>> 1. A Module is deserialized
>> 2. Deserialized Module is verified
>> 3. A service proxy is deserialized
>> 4. The service proxy is verified
>> 5. DownloadPermission is granted to the proxy ClassLoader (note that
>> it is a different ClassLoader than Module's ClassLoader)
>>
>> But how can we implement conditional Module verification?
>> We can have a locally installed verifier that just checks if
>> currently executing code has DownloadPermission and if that's the
>> case consider any Module trusted. But - of course - the client itself
>> has DownloadPermission, so this verifier would cause suppressing of
>> Module verification alltogether.
>> The idea is to have another permission that only the client has - the
>> verifier would check that permission and if the calling code has it -
>> consider Modules untrusted.
>> So now the sequence is as follows:
>> 1. A Module is deserialized
>> 2. DelegatedModuleTrustVerifier checks for
>> SuppressModuleInstallPermission.
>> 3. The client has it so DelegatedModuleTrustVerifier returns false
>> 4. The Module is verified using standard ProxyTrustVerifier
>> 5. A proxy is deserialized
>> 6. The proxy is verified
>> 7. The proxy is granted DownloadPermission
>> 8. The proxy tries to deserialize a subsequent object (annotated with
>> another Module)
>> 9. A Module is desecialized
>> 10. DelegatedModuleTrustVerifier checks for
>> SuppressModuleInstallPermission. Calling code does not have it so
>> DelegatedModuleTrustVerifier checks for DownloadPermission. Calling
>> code does have DownloadPermission (see p. 7) so we consider this
>> Module trusted
>> 11. We're done :)
>>
>> Michal
>>
>>
>> On Monday 11 of October 2010 13:06:18 Peter Firmstone wrote:
>>
>>> I don't completely follow, why do you need the additional permission?
>>>
>>> Perhaps we could have ModuleServiceProvider that only allows a
>>> reflective proxy? We can authenticate a reflective proxy because
>>> there's no downloaded code.
>>>
>>> interface ModuleServiceProvider {
>>> CodeSource[] getModuleCodeSources();
>>> Module getModule();
>>> }
>>>
>>> Setting up the Module from the ModuleServiceProvider, we can obtain the
>>> CodeSource URL and Certificate's before downloading any jar files for
>>> the module and check if a Module ClassLoader has been registered for
>>> the
>>> Subject.
>>>
>>> We can then dynamically grant Permissions to that ClassLoader (using
>>> the
>>> Module's class) with the Subject's Principals[], so it only has the
>>> necessary Permission's when run as the Subject of the Service.
>>>
>>> A marshalled smart proxy could be annotated with the
>>> ModuleServiceProvider, which is authenticated, and has constraints set,
>>> prior to instantiating a ClassLoader with the URL[]'s(if it doesn't
>>> already exist), then deserialize the Module into it (by setting the
>>> context ClassLoader) and use the new Module to provision the smart
>>> proxy's jar archives.
>>>
>>> Have a look at Gregg Wonderly's CodebaseAccessClassLoader too.
>>>
>>> http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/src/net/jini/loader
>>>
>>> /?pathrev=934258
>>>
>>> Some Permission Tips:
>>>
>>> 1. For simple Permission classes, extend Permission instead of
>>> BasicPermission if you can, if you don't need implement your own
>>> PermissionCollection, the Policy will provide an implementation
>>> for you (I provide a multi read PermissionCollection with my
>>> Policy Provider for better concurrency).
>>> 2. Try using Guard installModule = new InstallModulePermission();
>>> Then instead of calling the AccessController or SecurityManager,
>>> call installModule.checkGuard() instead, it gets the security
>>> manager for you and checks the Permission, when I've got the
>>> InternetSecurityManager finished, this will speed up your
>>> permission check for repeated checks.
>>>
>>> try {
>>> installModule.checkGuard(this);
>>> return true;
>>> } catch (SecurityException ex) {
>>> return false;
>>> }
>>>
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>> Michal Kleczek wrote:
>>>
>>>> Of course we need something more since the client has
>>>> InstallModulePermission it would suppress trust verification
>>>> alltogether. The simple fix is to have two permissions and suppress
>>>> trust verification only when we only have one of them. The client has
>>>> both, so we are going to verify trust.
>>>>
>>>> class InstallModulePermission extends BasicPermission {
>>>> }
>>>>
>>>> class SuppressInstallModulePermission extends BasicPermission {
>>>> }
>>>>
>>>> public class DelegatedModuleTrustVerifier implements TrustVerifier {
>>>>
>>>> private static final InstallModulePermission
>>>> INSTALL_MODULE_PERMISSION =
>>>> new InstallModulePermission();
>>>> private static final SuppressModuleTrustDelegationPermission
>>>> SUPPRESS_MODULE_TRUST_DELEGATION_PERMISSION =
>>>> new SuppressModuleTrustDelegationPermission();
>>>> @Override
>>>> public boolean isTrustedObject(Object o, Context cntxt) {
>>>> if (o instanceof Module) {
>>>> try {
>>>>
>>>> AccessController.checkPermission(SUPPRESS_MODULE_TRUST_DE
>>>> LEGATION_PERMISSION); return false;
>>>> }
>>>> catch (SecurityException suppressEx) {
>>>> try {
>>>>
>>>> AccessController.checkPermission(INSTALL_MODULE_PERMI
>>>> SSION); return true;
>>>> }
>>>> catch (SecurityException installEx) {
>>>> return false;
>>>> }
>>>> }
>>>> }
>>>> return false;
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> Michal
>>>>
>>>> On Monday 11 of October 2010 08:24:19 Michal Kleczek wrote:
>>>>
>>>>> On Monday 11 of October 2010 05:27:31 Peter Firmstone wrote:
>>>>>
>>>>>> Michal Kleczek wrote:
>>>>>>
>>>>>>> Some more thoughts.
>>>>>>>
>>>>>>> There is one scenario that is not covered here:
>>>>>>>
>>>>>>> I get an service, verify the module that loads its class using a
>>>>>>> ModuleAuthority that I trust. This service in turn downloads some
>>>>>>> other objects that it verified. There is no way I can delegate
>>>>>>> trust
>>>>>>> verification to the service - I must trust Modules (actually
>>>>>>> ModuleAuthorities) of those subsequent objects.
>>>>>>>
>>>>>>> 1. I have to have a way to allow or disallow module trust
>>>>>>> delegation
>>>>>>> (looks like a case for dynamic permission grants)
>>>>>>>
>>>>>> Currently PreferredClassLoader uses DownloadPermission to prevent or
>>>>>> allow a CodeSource class loading, because the CodeSource hasn't yet
>>>>>> been loaded, we cannot dynamically grant DownloadPermission to a
>>>>>> CodeSource, using DynamicPolicy.
>>>>>>
>>>>> Thanks for the hint.
>>>>> I think Module trust delegation can be achieved in a really simple
>>>>> way:
>>>>>
>>>>> class InstallModulePermission extends Permission {
>>>>> }
>>>>>
>>>>> //this TrustVerifier is installed locally on the client
>>>>> //so that delegation of Module trust verification can be done
>>>>> //by granting a service InstallModulePermission
>>>>>
>>>>> public class InstallModulePermissionVerifier implements
>>>>> TrustVerifier {
>>>>>
>>>>> private static final InstallModulePermission PERM =
>>>>> new InstallModulePermission()
>>>>> public boolean isTrustedObject(Object o, Context ctx) {
>>>>> try {
>>>>> if (o instanceof Module) {
>>>>> AccessController.checkPermission(PERM);
>>>>> return true;
>>>>> }
>>>>> return false;
>>>>> }
>>>>> catch (SecurityException e) {
>>>>> return false;
>>>>> }
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Michal
>>>>>
>>
>>
>
>
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Ok,
The ModuleServiceProvider adds a step:
1. A ModuleServiceProvider is deserialized (reflective proxy only)
(consider it a Module Factory, could rename it to that too).
2. Deserialized ModuleServiceProvider is verified
3. A Module cache is checked using the ModuleServiceProvider as a key
(weakly referenced).
4. If a Module exists in the cache, then that is used instead, goto 6.
5. If a Module doesn't exist in the cache for the Subject a new
Module will be created using the ModuleServiceProvider
1. CodeSource[] is obtained for the Module using the
ModuleServiceProvider
2. DownloadPermission is dynamically granted to all CodeSource
in the array CodeSource[] only.
3. DownloadPermission is only required to load the jar files
for the Module, via overriding
SecureClassLoader.getPermissions(CodeSource cs) as per
PreferredClassLoader.
4. The Module is deserialized, using the CodeSource[] URL's in
a new ClassLoader instance.
5. The Module is verified.
6. The Module is granted GrantPermission(DownloadPermission)
7. The Module knows which CodeSources require
DownloadPermission and grant's these dynamically on an as
needed basis.
8. The Module needs a guard to check the caller has sufficient
permission to use it, this would be created during module
construction, we need to define a standard guard permissions
for each method.
9. The Module is stored in the cache associated with the
ModuleServiceProvider.
6. The Service Proxy is unmarshalled.
7. The service is verified (it has to authenticate with the same
Subject as the ModuleServiceProvider).
8. The service is used. (Constraints ensure the service authenticates
every method invocation).
Note: The ModuleServiceProvider has the same Subject as the Service Proxy.
Module needs an additional method:
ClassLoader getClassLoader(Subject s);
The Module needs to have a Subject parameter added to it's other methods
too, the Module already know's the Codebase URL's, since this is it's
responsibility, however it needs to ensure that different Subject's
don't share ClassLoaders, in case multiple Subjects are using one Module
with identical CodeSource, in the case where the Module Service provides
for a number of Subjects.
The Module Service, knows which jar files, module / package versions are
in use for the requested classes.
If Service Proxy's had OSGi embedded, they could be shutdown and
reloaded with new Module versions, this would be synchronous with the
Module Service.
Ordinary services might simply be stopped and re looked up with updated
jar files and annotated with a new ModuleServiceProvider instance.
We can choose to limit other permission's also like SocketPermission's
to particular domains.
Can we cache jar files somehow based on their URL?
I'm not certain if this is right, what do you think?
Cheers,
Peter.
Michal Kleczek wrote:
> Thanks for the tips on using Guard and subclassing Permission - I will update
> the code.
>
> But I am not completely sure I follow your idea of ModuleServiceProvider.
>
> I'll try to explain why I think two permissions are needed.
> Let's imagine a simple scenario:
>
> 1. A client gets a service proxy.
> 2. Before actually downloading any code and deserializing the proxy the client
> wants to verify a Module that it received as annotation.
> 3. After the proxy is deserialized the client wants to grant the proxy a
> permission to deserialize other objects that possibly will require other
> Modules to be downloaded.
>
> So the following steps are performed:
> 1. A Module is deserialized
> 2. Deserialized Module is verified
> 3. A service proxy is deserialized
> 4. The service proxy is verified
> 5. DownloadPermission is granted to the proxy ClassLoader (note that it is a
> different ClassLoader than Module's ClassLoader)
>
> But how can we implement conditional Module verification?
> We can have a locally installed verifier that just checks if currently
> executing code has DownloadPermission and if that's the case consider any
> Module trusted. But - of course - the client itself has DownloadPermission, so
> this verifier would cause suppressing of Module verification alltogether.
> The idea is to have another permission that only the client has - the verifier
> would check that permission and if the calling code has it - consider Modules
> untrusted.
> So now the sequence is as follows:
> 1. A Module is deserialized
> 2. DelegatedModuleTrustVerifier checks for SuppressModuleInstallPermission.
> 3. The client has it so DelegatedModuleTrustVerifier returns false
> 4. The Module is verified using standard ProxyTrustVerifier
> 5. A proxy is deserialized
> 6. The proxy is verified
> 7. The proxy is granted DownloadPermission
> 8. The proxy tries to deserialize a subsequent object (annotated with another
> Module)
> 9. A Module is desecialized
> 10. DelegatedModuleTrustVerifier checks for SuppressModuleInstallPermission.
> Calling code does not have it so DelegatedModuleTrustVerifier checks for
> DownloadPermission. Calling code does have DownloadPermission (see p. 7) so we
> consider this Module trusted
> 11. We're done :)
>
> Michal
>
>
> On Monday 11 of October 2010 13:06:18 Peter Firmstone wrote:
>
>> I don't completely follow, why do you need the additional permission?
>>
>> Perhaps we could have ModuleServiceProvider that only allows a
>> reflective proxy? We can authenticate a reflective proxy because
>> there's no downloaded code.
>>
>> interface ModuleServiceProvider {
>> CodeSource[] getModuleCodeSources();
>> Module getModule();
>> }
>>
>> Setting up the Module from the ModuleServiceProvider, we can obtain the
>> CodeSource URL and Certificate's before downloading any jar files for
>> the module and check if a Module ClassLoader has been registered for the
>> Subject.
>>
>> We can then dynamically grant Permissions to that ClassLoader (using the
>> Module's class) with the Subject's Principals[], so it only has the
>> necessary Permission's when run as the Subject of the Service.
>>
>> A marshalled smart proxy could be annotated with the
>> ModuleServiceProvider, which is authenticated, and has constraints set,
>> prior to instantiating a ClassLoader with the URL[]'s(if it doesn't
>> already exist), then deserialize the Module into it (by setting the
>> context ClassLoader) and use the new Module to provision the smart
>> proxy's jar archives.
>>
>> Have a look at Gregg Wonderly's CodebaseAccessClassLoader too.
>>
>> http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/src/net/jini/loader
>> /?pathrev=934258
>>
>> Some Permission Tips:
>>
>> 1. For simple Permission classes, extend Permission instead of
>> BasicPermission if you can, if you don't need implement your own
>> PermissionCollection, the Policy will provide an implementation
>> for you (I provide a multi read PermissionCollection with my
>> Policy Provider for better concurrency).
>> 2. Try using Guard installModule = new InstallModulePermission();
>> Then instead of calling the AccessController or SecurityManager,
>> call installModule.checkGuard() instead, it gets the security
>> manager for you and checks the Permission, when I've got the
>> InternetSecurityManager finished, this will speed up your
>> permission check for repeated checks.
>>
>> try {
>> installModule.checkGuard(this);
>> return true;
>> } catch (SecurityException ex) {
>> return false;
>> }
>>
>>
>> Cheers,
>>
>> Peter.
>>
>> Michal Kleczek wrote:
>>
>>> Of course we need something more since the client has
>>> InstallModulePermission it would suppress trust verification
>>> alltogether. The simple fix is to have two permissions and suppress
>>> trust verification only when we only have one of them. The client has
>>> both, so we are going to verify trust.
>>>
>>> class InstallModulePermission extends BasicPermission {
>>> }
>>>
>>> class SuppressInstallModulePermission extends BasicPermission {
>>> }
>>>
>>> public class DelegatedModuleTrustVerifier implements TrustVerifier {
>>>
>>> private static final InstallModulePermission
>>> INSTALL_MODULE_PERMISSION =
>>>
>>> new InstallModulePermission();
>>>
>>> private static final SuppressModuleTrustDelegationPermission
>>>
>>> SUPPRESS_MODULE_TRUST_DELEGATION_PERMISSION =
>>>
>>> new SuppressModuleTrustDelegationPermission();
>>>
>>> @Override
>>> public boolean isTrustedObject(Object o, Context cntxt) {
>>>
>>> if (o instanceof Module) {
>>>
>>> try {
>>>
>>> AccessController.checkPermission(SUPPRESS_MODULE_TRUST_DE
>>> LEGATION_PERMISSION); return false;
>>>
>>> }
>>> catch (SecurityException suppressEx) {
>>>
>>> try {
>>>
>>> AccessController.checkPermission(INSTALL_MODULE_PERMI
>>> SSION); return true;
>>>
>>> }
>>> catch (SecurityException installEx) {
>>>
>>> return false;
>>>
>>> }
>>>
>>> }
>>>
>>> }
>>>
>>> return false;
>>>
>>> }
>>>
>>> }
>>>
>>>
>>> Michal
>>>
>>> On Monday 11 of October 2010 08:24:19 Michal Kleczek wrote:
>>>
>>>> On Monday 11 of October 2010 05:27:31 Peter Firmstone wrote:
>>>>
>>>>> Michal Kleczek wrote:
>>>>>
>>>>>> Some more thoughts.
>>>>>>
>>>>>> There is one scenario that is not covered here:
>>>>>>
>>>>>> I get an service, verify the module that loads its class using a
>>>>>> ModuleAuthority that I trust. This service in turn downloads some
>>>>>> other objects that it verified. There is no way I can delegate trust
>>>>>> verification to the service - I must trust Modules (actually
>>>>>> ModuleAuthorities) of those subsequent objects.
>>>>>>
>>>>>> 1. I have to have a way to allow or disallow module trust delegation
>>>>>> (looks like a case for dynamic permission grants)
>>>>>>
>>>>> Currently PreferredClassLoader uses DownloadPermission to prevent or
>>>>> allow a CodeSource class loading, because the CodeSource hasn't yet
>>>>> been loaded, we cannot dynamically grant DownloadPermission to a
>>>>> CodeSource, using DynamicPolicy.
>>>>>
>>>> Thanks for the hint.
>>>> I think Module trust delegation can be achieved in a really simple way:
>>>>
>>>> class InstallModulePermission extends Permission {
>>>> }
>>>>
>>>> //this TrustVerifier is installed locally on the client
>>>> //so that delegation of Module trust verification can be done
>>>> //by granting a service InstallModulePermission
>>>>
>>>> public class InstallModulePermissionVerifier implements TrustVerifier {
>>>>
>>>> private static final InstallModulePermission PERM =
>>>>
>>>> new InstallModulePermission()
>>>>
>>>> public boolean isTrustedObject(Object o, Context ctx) {
>>>>
>>>> try {
>>>>
>>>> if (o instanceof Module) {
>>>>
>>>> AccessController.checkPermission(PERM);
>>>> return true;
>>>>
>>>> }
>>>>
>>>> return false;
>>>>
>>>> }
>>>> catch (SecurityException e) {
>>>>
>>>> return false;
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> What do you think?
>>>>
>>>> Michal
>>>>
>
>
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Thanks for the tips on using Guard and subclassing Permission - I will update
the code.
But I am not completely sure I follow your idea of ModuleServiceProvider.
I'll try to explain why I think two permissions are needed.
Let's imagine a simple scenario:
1. A client gets a service proxy.
2. Before actually downloading any code and deserializing the proxy the client
wants to verify a Module that it received as annotation.
3. After the proxy is deserialized the client wants to grant the proxy a
permission to deserialize other objects that possibly will require other
Modules to be downloaded.
So the following steps are performed:
1. A Module is deserialized
2. Deserialized Module is verified
3. A service proxy is deserialized
4. The service proxy is verified
5. DownloadPermission is granted to the proxy ClassLoader (note that it is a
different ClassLoader than Module's ClassLoader)
But how can we implement conditional Module verification?
We can have a locally installed verifier that just checks if currently
executing code has DownloadPermission and if that's the case consider any
Module trusted. But - of course - the client itself has DownloadPermission, so
this verifier would cause suppressing of Module verification alltogether.
The idea is to have another permission that only the client has - the verifier
would check that permission and if the calling code has it - consider Modules
untrusted.
So now the sequence is as follows:
1. A Module is deserialized
2. DelegatedModuleTrustVerifier checks for SuppressModuleInstallPermission.
3. The client has it so DelegatedModuleTrustVerifier returns false
4. The Module is verified using standard ProxyTrustVerifier
5. A proxy is deserialized
6. The proxy is verified
7. The proxy is granted DownloadPermission
8. The proxy tries to deserialize a subsequent object (annotated with another
Module)
9. A Module is desecialized
10. DelegatedModuleTrustVerifier checks for SuppressModuleInstallPermission.
Calling code does not have it so DelegatedModuleTrustVerifier checks for
DownloadPermission. Calling code does have DownloadPermission (see p. 7) so we
consider this Module trusted
11. We're done :)
Michal
On Monday 11 of October 2010 13:06:18 Peter Firmstone wrote:
> I don't completely follow, why do you need the additional permission?
>
> Perhaps we could have ModuleServiceProvider that only allows a
> reflective proxy? We can authenticate a reflective proxy because
> there's no downloaded code.
>
> interface ModuleServiceProvider {
> CodeSource[] getModuleCodeSources();
> Module getModule();
> }
>
> Setting up the Module from the ModuleServiceProvider, we can obtain the
> CodeSource URL and Certificate's before downloading any jar files for
> the module and check if a Module ClassLoader has been registered for the
> Subject.
>
> We can then dynamically grant Permissions to that ClassLoader (using the
> Module's class) with the Subject's Principals[], so it only has the
> necessary Permission's when run as the Subject of the Service.
>
> A marshalled smart proxy could be annotated with the
> ModuleServiceProvider, which is authenticated, and has constraints set,
> prior to instantiating a ClassLoader with the URL[]'s(if it doesn't
> already exist), then deserialize the Module into it (by setting the
> context ClassLoader) and use the new Module to provision the smart
> proxy's jar archives.
>
> Have a look at Gregg Wonderly's CodebaseAccessClassLoader too.
>
> http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/src/net/jini/loader
> /?pathrev=934258
>
> Some Permission Tips:
>
> 1. For simple Permission classes, extend Permission instead of
> BasicPermission if you can, if you don't need implement your own
> PermissionCollection, the Policy will provide an implementation
> for you (I provide a multi read PermissionCollection with my
> Policy Provider for better concurrency).
> 2. Try using Guard installModule = new InstallModulePermission();
> Then instead of calling the AccessController or SecurityManager,
> call installModule.checkGuard() instead, it gets the security
> manager for you and checks the Permission, when I've got the
> InternetSecurityManager finished, this will speed up your
> permission check for repeated checks.
>
> try {
> installModule.checkGuard(this);
> return true;
> } catch (SecurityException ex) {
> return false;
> }
>
>
> Cheers,
>
> Peter.
>
> Michal Kleczek wrote:
> > Of course we need something more since the client has
> > InstallModulePermission it would suppress trust verification
> > alltogether. The simple fix is to have two permissions and suppress
> > trust verification only when we only have one of them. The client has
> > both, so we are going to verify trust.
> >
> > class InstallModulePermission extends BasicPermission {
> > }
> >
> > class SuppressInstallModulePermission extends BasicPermission {
> > }
> >
> > public class DelegatedModuleTrustVerifier implements TrustVerifier {
> >
> > private static final InstallModulePermission
> > INSTALL_MODULE_PERMISSION =
> >
> > new InstallModulePermission();
> >
> > private static final SuppressModuleTrustDelegationPermission
> >
> > SUPPRESS_MODULE_TRUST_DELEGATION_PERMISSION =
> >
> > new SuppressModuleTrustDelegationPermission();
> >
> > @Override
> > public boolean isTrustedObject(Object o, Context cntxt) {
> >
> > if (o instanceof Module) {
> >
> > try {
> >
> > AccessController.checkPermission(SUPPRESS_MODULE_TRUST_DE
> > LEGATION_PERMISSION); return false;
> >
> > }
> > catch (SecurityException suppressEx) {
> >
> > try {
> >
> > AccessController.checkPermission(INSTALL_MODULE_PERMI
> > SSION); return true;
> >
> > }
> > catch (SecurityException installEx) {
> >
> > return false;
> >
> > }
> >
> > }
> >
> > }
> >
> > return false;
> >
> > }
> >
> > }
> >
> >
> > Michal
> >
> > On Monday 11 of October 2010 08:24:19 Michal Kleczek wrote:
> >> On Monday 11 of October 2010 05:27:31 Peter Firmstone wrote:
> >>> Michal Kleczek wrote:
> >>>> Some more thoughts.
> >>>>
> >>>> There is one scenario that is not covered here:
> >>>>
> >>>> I get an service, verify the module that loads its class using a
> >>>> ModuleAuthority that I trust. This service in turn downloads some
> >>>> other objects that it verified. There is no way I can delegate trust
> >>>> verification to the service - I must trust Modules (actually
> >>>> ModuleAuthorities) of those subsequent objects.
> >>>>
> >>>> 1. I have to have a way to allow or disallow module trust delegation
> >>>> (looks like a case for dynamic permission grants)
> >>>
> >>> Currently PreferredClassLoader uses DownloadPermission to prevent or
> >>> allow a CodeSource class loading, because the CodeSource hasn't yet
> >>> been loaded, we cannot dynamically grant DownloadPermission to a
> >>> CodeSource, using DynamicPolicy.
> >>
> >> Thanks for the hint.
> >> I think Module trust delegation can be achieved in a really simple way:
> >>
> >> class InstallModulePermission extends Permission {
> >> }
> >>
> >> //this TrustVerifier is installed locally on the client
> >> //so that delegation of Module trust verification can be done
> >> //by granting a service InstallModulePermission
> >>
> >> public class InstallModulePermissionVerifier implements TrustVerifier {
> >>
> >> private static final InstallModulePermission PERM =
> >>
> >> new InstallModulePermission()
> >>
> >> public boolean isTrustedObject(Object o, Context ctx) {
> >>
> >> try {
> >>
> >> if (o instanceof Module) {
> >>
> >> AccessController.checkPermission(PERM);
> >> return true;
> >>
> >> }
> >>
> >> return false;
> >>
> >> }
> >> catch (SecurityException e) {
> >>
> >> return false;
> >>
> >> }
> >>
> >> }
> >>
> >> }
> >>
> >> What do you think?
> >>
> >> Michal
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Looks like we don't need InstallModulePermission - DownloadPermission should
be granted to services instead.
Attached is a version that I'm going to start testing - what I want to do is
to run Reggie configured to use ModuleExporter and KerberosServerEndpoint.
That way the client will contact Reggie to verify the codebase.
Michal
On Monday 11 of October 2010 09:46:18 Michal Kleczek wrote:
> Of course we need something more since the client has
> InstallModulePermission it would suppress trust verification alltogether.
> The simple fix is to have two permissions and suppress trust verification
> only when we only have one of them. The client has both, so we are going
> to verify trust.
>
> class InstallModulePermission extends BasicPermission {
> }
>
> class SuppressInstallModulePermission extends BasicPermission {
> }
>
> public class DelegatedModuleTrustVerifier implements TrustVerifier {
>
> private static final InstallModulePermission INSTALL_MODULE_PERMISSION
> = new InstallModulePermission();
> private static final SuppressModuleTrustDelegationPermission
> SUPPRESS_MODULE_TRUST_DELEGATION_PERMISSION =
> new SuppressModuleTrustDelegationPermission();
>
> @Override
> public boolean isTrustedObject(Object o, Context cntxt) {
> if (o instanceof Module) {
> try {
>
> AccessController.checkPermission(SUPPRESS_MODULE_TRUST_DELEGATION_PERMISSI
> ON); return false;
> }
> catch (SecurityException suppressEx) {
> try {
>
> AccessController.checkPermission(INSTALL_MODULE_PERMISSION); return true;
> }
> catch (SecurityException installEx) {
> return false;
> }
> }
> }
>
> return false;
> }
>
> }
>
>
> Michal
>
> On Monday 11 of October 2010 08:24:19 Michal Kleczek wrote:
> > On Monday 11 of October 2010 05:27:31 Peter Firmstone wrote:
> > > Michal Kleczek wrote:
> > > > Some more thoughts.
> > > >
> > > > There is one scenario that is not covered here:
> > > >
> > > > I get an service, verify the module that loads its class using a
> > > > ModuleAuthority that I trust. This service in turn downloads some
> > > > other objects that it verified. There is no way I can delegate trust
> > > > verification to the service - I must trust Modules (actually
> > > > ModuleAuthorities) of those subsequent objects.
> > > >
> > > > 1. I have to have a way to allow or disallow module trust delegation
> > > > (looks like a case for dynamic permission grants)
> > >
> > > Currently PreferredClassLoader uses DownloadPermission to prevent or
> > > allow a CodeSource class loading, because the CodeSource hasn't yet
> > > been loaded, we cannot dynamically grant DownloadPermission to a
> > > CodeSource, using DynamicPolicy.
> >
> > Thanks for the hint.
> > I think Module trust delegation can be achieved in a really simple way:
> >
> > class InstallModulePermission extends Permission {
> > }
> >
> > //this TrustVerifier is installed locally on the client
> > //so that delegation of Module trust verification can be done
> > //by granting a service InstallModulePermission
> >
> > public class InstallModulePermissionVerifier implements TrustVerifier {
> >
> > private static final InstallModulePermission PERM =
> >
> > new InstallModulePermission()
> >
> > public boolean isTrustedObject(Object o, Context ctx) {
> >
> > try {
> >
> > if (o instanceof Module) {
> >
> > AccessController.checkPermission(PERM);
> > return true;
> >
> > }
> >
> > return false;
> >
> > }
> > catch (SecurityException e) {
> >
> > return false;
> >
> > }
> >
> > }
> >
> > }
> >
> > What do you think?
> >
> > Michal
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
I don't completely follow, why do you need the additional permission?
Perhaps we could have ModuleServiceProvider that only allows a
reflective proxy? We can authenticate a reflective proxy because
there's no downloaded code.
interface ModuleServiceProvider {
CodeSource[] getModuleCodeSources();
Module getModule();
}
Setting up the Module from the ModuleServiceProvider, we can obtain the
CodeSource URL and Certificate's before downloading any jar files for
the module and check if a Module ClassLoader has been registered for the
Subject.
We can then dynamically grant Permissions to that ClassLoader (using the
Module's class) with the Subject's Principals[], so it only has the
necessary Permission's when run as the Subject of the Service.
A marshalled smart proxy could be annotated with the
ModuleServiceProvider, which is authenticated, and has constraints set,
prior to instantiating a ClassLoader with the URL[]'s(if it doesn't
already exist), then deserialize the Module into it (by setting the
context ClassLoader) and use the new Module to provision the smart
proxy's jar archives.
Have a look at Gregg Wonderly's CodebaseAccessClassLoader too.
http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/src/net/jini/loader/?pathrev=934258
Some Permission Tips:
1. For simple Permission classes, extend Permission instead of
BasicPermission if you can, if you don't need implement your own
PermissionCollection, the Policy will provide an implementation
for you (I provide a multi read PermissionCollection with my
Policy Provider for better concurrency).
2. Try using Guard installModule = new InstallModulePermission();
Then instead of calling the AccessController or SecurityManager,
call installModule.checkGuard() instead, it gets the security
manager for you and checks the Permission, when I've got the
InternetSecurityManager finished, this will speed up your
permission check for repeated checks.
try {
installModule.checkGuard(this);
return true;
} catch (SecurityException ex) {
return false;
}
Cheers,
Peter.
Michal Kleczek wrote:
> Of course we need something more since the client has InstallModulePermission
> it would suppress trust verification alltogether. The simple fix is to have two
> permissions and suppress trust verification only when we only have one of them.
> The client has both, so we are going to verify trust.
>
> class InstallModulePermission extends BasicPermission {
> }
>
> class SuppressInstallModulePermission extends BasicPermission {
> }
>
> public class DelegatedModuleTrustVerifier implements TrustVerifier {
>
> private static final InstallModulePermission INSTALL_MODULE_PERMISSION =
> new InstallModulePermission();
> private static final SuppressModuleTrustDelegationPermission
> SUPPRESS_MODULE_TRUST_DELEGATION_PERMISSION =
> new SuppressModuleTrustDelegationPermission();
>
> @Override
> public boolean isTrustedObject(Object o, Context cntxt) {
> if (o instanceof Module) {
> try {
> AccessController.checkPermission(SUPPRESS_MODULE_TRUST_DELEGATION_PERMISSION);
> return false;
> }
> catch (SecurityException suppressEx) {
> try {
> AccessController.checkPermission(INSTALL_MODULE_PERMISSION);
> return true;
> }
> catch (SecurityException installEx) {
> return false;
> }
> }
> }
>
> return false;
> }
>
> }
>
>
> Michal
>
> On Monday 11 of October 2010 08:24:19 Michal Kleczek wrote:
>
>> On Monday 11 of October 2010 05:27:31 Peter Firmstone wrote:
>>
>>> Michal Kleczek wrote:
>>>
>>>> Some more thoughts.
>>>>
>>>> There is one scenario that is not covered here:
>>>>
>>>> I get an service, verify the module that loads its class using a
>>>> ModuleAuthority that I trust. This service in turn downloads some other
>>>> objects that it verified. There is no way I can delegate trust
>>>> verification to the service - I must trust Modules (actually
>>>> ModuleAuthorities) of those subsequent objects.
>>>>
>>>> 1. I have to have a way to allow or disallow module trust delegation
>>>> (looks like a case for dynamic permission grants)
>>>>
>>> Currently PreferredClassLoader uses DownloadPermission to prevent or
>>> allow a CodeSource class loading, because the CodeSource hasn't yet been
>>> loaded, we cannot dynamically grant DownloadPermission to a CodeSource,
>>> using DynamicPolicy.
>>>
>> Thanks for the hint.
>> I think Module trust delegation can be achieved in a really simple way:
>>
>> class InstallModulePermission extends Permission {
>> }
>>
>> //this TrustVerifier is installed locally on the client
>> //so that delegation of Module trust verification can be done
>> //by granting a service InstallModulePermission
>>
>> public class InstallModulePermissionVerifier implements TrustVerifier {
>>
>> private static final InstallModulePermission PERM =
>> new InstallModulePermission()
>>
>> public boolean isTrustedObject(Object o, Context ctx) {
>> try {
>> if (o instanceof Module) {
>> AccessController.checkPermission(PERM);
>> return true;
>> }
>>
>> return false;
>> }
>> catch (SecurityException e) {
>> return false;
>> }
>> }
>>
>> }
>>
>> What do you think?
>>
>> Michal
>>
>
>
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Of course we need something more since the client has InstallModulePermission
it would suppress trust verification alltogether. The simple fix is to have two
permissions and suppress trust verification only when we only have one of them.
The client has both, so we are going to verify trust.
class InstallModulePermission extends BasicPermission {
}
class SuppressInstallModulePermission extends BasicPermission {
}
public class DelegatedModuleTrustVerifier implements TrustVerifier {
private static final InstallModulePermission INSTALL_MODULE_PERMISSION =
new InstallModulePermission();
private static final SuppressModuleTrustDelegationPermission
SUPPRESS_MODULE_TRUST_DELEGATION_PERMISSION =
new SuppressModuleTrustDelegationPermission();
@Override
public boolean isTrustedObject(Object o, Context cntxt) {
if (o instanceof Module) {
try {
AccessController.checkPermission(SUPPRESS_MODULE_TRUST_DELEGATION_PERMISSION);
return false;
}
catch (SecurityException suppressEx) {
try {
AccessController.checkPermission(INSTALL_MODULE_PERMISSION);
return true;
}
catch (SecurityException installEx) {
return false;
}
}
}
return false;
}
}
Michal
On Monday 11 of October 2010 08:24:19 Michal Kleczek wrote:
> On Monday 11 of October 2010 05:27:31 Peter Firmstone wrote:
> > Michal Kleczek wrote:
> > > Some more thoughts.
> > >
> > > There is one scenario that is not covered here:
> > >
> > > I get an service, verify the module that loads its class using a
> > > ModuleAuthority that I trust. This service in turn downloads some other
> > > objects that it verified. There is no way I can delegate trust
> > > verification to the service - I must trust Modules (actually
> > > ModuleAuthorities) of those subsequent objects.
> > >
> > > 1. I have to have a way to allow or disallow module trust delegation
> > > (looks like a case for dynamic permission grants)
> >
> > Currently PreferredClassLoader uses DownloadPermission to prevent or
> > allow a CodeSource class loading, because the CodeSource hasn't yet been
> > loaded, we cannot dynamically grant DownloadPermission to a CodeSource,
> > using DynamicPolicy.
>
> Thanks for the hint.
> I think Module trust delegation can be achieved in a really simple way:
>
> class InstallModulePermission extends Permission {
> }
>
> //this TrustVerifier is installed locally on the client
> //so that delegation of Module trust verification can be done
> //by granting a service InstallModulePermission
>
> public class InstallModulePermissionVerifier implements TrustVerifier {
>
> private static final InstallModulePermission PERM =
> new InstallModulePermission()
>
> public boolean isTrustedObject(Object o, Context ctx) {
> try {
> if (o instanceof Module) {
> AccessController.checkPermission(PERM);
> return true;
> }
>
> return false;
> }
> catch (SecurityException e) {
> return false;
> }
> }
>
> }
>
> What do you think?
>
> Michal
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Monday 11 of October 2010 05:27:31 Peter Firmstone wrote:
> Michal Kleczek wrote:
> > Some more thoughts.
> >
> > There is one scenario that is not covered here:
> >
> > I get an service, verify the module that loads its class using a
> > ModuleAuthority that I trust. This service in turn downloads some other
> > objects that it verified. There is no way I can delegate trust
> > verification to the service - I must trust Modules (actually
> > ModuleAuthorities) of those subsequent objects.
> >
> > 1. I have to have a way to allow or disallow module trust delegation
> > (looks like a case for dynamic permission grants)
>
> Currently PreferredClassLoader uses DownloadPermission to prevent or
> allow a CodeSource class loading, because the CodeSource hasn't yet been
> loaded, we cannot dynamically grant DownloadPermission to a CodeSource,
> using DynamicPolicy.
Thanks for the hint.
I think Module trust delegation can be achieved in a really simple way:
class InstallModulePermission extends Permission {
}
//this TrustVerifier is installed locally on the client
//so that delegation of Module trust verification can be done
//by granting a service InstallModulePermission
public class InstallModulePermissionVerifier implements TrustVerifier {
private static final InstallModulePermission PERM =
new InstallModulePermission()
public boolean isTrustedObject(Object o, Context ctx) {
try {
if (o instanceof Module) {
AccessController.checkPermission(PERM);
return true;
}
return false;
}
catch (SecurityException e) {
return false;
}
}
}
What do you think?
Michal
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Michal Kleczek wrote:
>> Some more thoughts.
>>
>> There is one scenario that is not covered here:
>>
>> I get an service, verify the module that loads its class using a
>> ModuleAuthority that I trust. This service in turn downloads some
>> other objects that it verified. There is no way I can delegate trust
>> verification to the service - I must trust Modules (actually
>> ModuleAuthorities) of those subsequent objects.
>>
>> 1. I have to have a way to allow or disallow module trust delegation
>> (looks like a case for dynamic permission grants)
>>
>
> Currently PreferredClassLoader uses DownloadPermission to prevent or
> allow a CodeSource class loading, because the CodeSource hasn't yet
> been loaded, we cannot dynamically grant DownloadPermission to a
> CodeSource, using DynamicPolicy.
>
> However I have RevokeableDyanamicPolicy (browse svn under
> jtsk/skunk/pepe/src/org/apache/river/security) and an implementation
> that allows dynamic grant's for CodeSource's.
grant CodeSource with Principal[], so it doesn't apply to other Services
that haven't yet been authenticated, requires some mods to
PreferredClassLoader, since it creates a ProtectionDomain for the
permission check.
>
> This will allow us to delay granting DownloadPermission until after
> authentication, forcing the service to initially use a local Module.
>
> Once we've authenticated we know the Subject, so we could recreate the
> proxy in a new ClassLoader that uses the Subject in it's identity. We
> already recreate the proxy for client constraints.
>
> This ClassLoader would represent the Service Proxy's private
> namespace, under which an embedded OSGi or Maven or other management
> framework or libraries could be loaded privately by the proxy, solely
> for its use.
>
> Since remote method call threads are run with the remote Subject, we
> can find the correct ClassLoader, without using a CodeSource hack.
>
> Cheers,
>
> Peter.
>> 2. This delegation has to be automatic (IOW the service does not have
>> to do anything - it is solely my decision to delegate)
>>
>> Any ideas?
>> Michal
>>
>> On Thursday 07 of October 2010 21:57:48 Michal Kleczek wrote:
>>
>>> So...
>>> I've spent a day on some thinking and prototyping and hopefully I
>>> got an
>>> idea. Here is an outline:
>>>
>>> 1. We annotate classes with an object implementing Module interface:
>>> interface Module {
>>> //methods copied from ClassLoading but there is no annotation
>>> argument
>>> Class loadClass(...);
>>> Class loadProxyClass();
>>> }
>>> This makes class loading pluggable - a service can designate it's
>>> own class
>>> loading mechanism.
>>> Note that the methods take boolean verifyCodebaseIntegrity argument. I
>>> think it could be replaced by placing constraints on a Module.
>>>
>>> 2. Before using a Module we prepare it using a ProxyPreparer - that
>>> way we
>>> make sure we trust the Module before letting it load classes
>>>
>>> 3. We have a default implementation of Module that delegates class
>>> loading
>>> to ClassLoading:
>>> RmiModule implements Module {
>>> private String annotation;
>>> }
>>>
>>> 4. There is a single instance of RmiModule called BOOTSTRAP that we
>>> use to
>>> load RmiModule class. This is implemented in:
>>> RmiModule {
>>> ...
>>> static Module getModuleOf(final Class cl) {
>>> /*
>>> * RmiModule is equivalent of String annotation
>>> * so it should be available locally
>>> */
>>> if (cl == RmiModule.class) {
>>> return getBootstrap();
>>> }
>>>
>>> final ClassLoader loader = getClassLoader(cl);
>>> if (loader instanceof ModuleClassLoader) {
>>> return ((ModuleClassLoader) loader).getModule();
>>>
>>> }
>>>
>>> final String annotation =
>>> RMIClassLoader.getClassAnnotation(cl);
>>> return annotation != null ? RmiModule.getInstance(
>>> annotation,getModuleTrust(loader)) : getBootstrap();
>>> }
>>> ...
>>> }
>>>
>>> 5. We use the above method in annotateClass and annotateProxyClass
>>> of our
>>> MarshalOutputStream
>>>
>>> 6. RmiModule can be verified by ProxyTrustVerifier. It's ProxyTrust
>>> implementation delegates TrustVerifier retrieval to:
>>> public interface ModuleAuthority extends Remote {
>>> TrustVerifier getModuleVerifier() throws RemoteException;
>>> }
>>>
>>> 7. We implement some helper functions that make it simpler to export a
>>> service and provide its clients with either third party
>>> ModuleAuthority or
>>> designate itself as a ModuleAuthority.
>>>
>>> 8. Before all this is implemented in PreferredClassProvider we have to
>>> cache association between a ClassLoader and a Module. It's
>>> implemented in
>>> RmiModule.
>>>
>>> 9. If we implement it in PreferredClassProvider our ClassLoaders can
>>> keep a
>>> reference to associated Module
>>>
>>> 10. If we implement it in PreferredClassProvider we can have different
>>> ClassLoaders for the same annotation but different ModuleAuthority -
>>> that
>>> would actually allow us to grant permissions to Modules - before
>>> that two
>>> different Modules with the same annotation are going to share
>>> permissions.
>>>
>>> I've attached a prototype implementation (note - it is a proto-proto-
>>> prototype) so that you guys can verify if you have some spare time.
>>> Don't know if mailing list server allows attachments.
>>>
>>> Michal
>>>
>>> On Tuesday 05 of October 2010 16:48:22 Michal Kleczek wrote:
>>>
>>>> On Tuesday 05 of October 2010 16:36:47 Gregg Wonderly wrote:
>>>>
>>>>> On 10/1/2010 12:38 PM, Michal Kleczek wrote:
>>>>>
>>>>>> When I think about it some more - the below idea is not enough
>>>>>> and we
>>>>>> need a more general solution.
>>>>>> How about class annotation not being a String but rather an
>>>>>> object...
>>>>>> I have to give it some more thought.
>>>>>>
>>>>> There are been some thought and discussion about doing this. It is
>>>>> possible, but the problem becomes that if you send an object with the
>>>>> annotation, then how does the receiver unmarshall that object? Is
>>>>> that
>>>>> object something that everyone knows about ahead of time?
>>>>>
>>>> My line of thought was - yes. It would have to be something similar to
>>>> ProxyTrust - a factory to receive an Unmarshaller.
>>>> I haven't really given it enough thought.
>>>>
>>>> But I am more and more convinced that doing that at the higher (proxy
>>>> preparation) level - as I described it earlier - could actually be
>>>> enough.
>>>>
>>>> Michal
>>>>
>>
>>
>
>
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Michal Kleczek wrote:
> Some more thoughts.
>
> There is one scenario that is not covered here:
>
> I get an service, verify the module that loads its class using a
> ModuleAuthority that I trust. This service in turn downloads some other
> objects that it verified. There is no way I can delegate trust verification to
> the service - I must trust Modules (actually ModuleAuthorities) of those
> subsequent objects.
>
> 1. I have to have a way to allow or disallow module trust delegation (looks
> like a case for dynamic permission grants)
>
Currently PreferredClassLoader uses DownloadPermission to prevent or
allow a CodeSource class loading, because the CodeSource hasn't yet been
loaded, we cannot dynamically grant DownloadPermission to a CodeSource,
using DynamicPolicy.
However I have RevokeableDyanamicPolicy (browse svn under
jtsk/skunk/pepe/src/org/apache/river/security) and an implementation
that allows dynamic grant's for CodeSource's.
This will allow us to delay granting DownloadPermission until after
authentication, forcing the service to initially use a local Module.
Once we've authenticated we know the Subject, so we could recreate the
proxy in a new ClassLoader that uses the Subject in it's identity. We
already recreate the proxy for client constraints.
This ClassLoader would represent the Service Proxy's private namespace,
under which an embedded OSGi or Maven or other management framework or
libraries could be loaded privately by the proxy, solely for its use.
Since remote method call threads are run with the remote Subject, we can
find the correct ClassLoader, without using a CodeSource hack.
Cheers,
Peter.
> 2. This delegation has to be automatic (IOW the service does not have to do
> anything - it is solely my decision to delegate)
>
> Any ideas?
> Michal
>
> On Thursday 07 of October 2010 21:57:48 Michal Kleczek wrote:
>
>> So...
>> I've spent a day on some thinking and prototyping and hopefully I got an
>> idea. Here is an outline:
>>
>> 1. We annotate classes with an object implementing Module interface:
>> interface Module {
>> //methods copied from ClassLoading but there is no annotation argument
>> Class loadClass(...);
>> Class loadProxyClass();
>> }
>> This makes class loading pluggable - a service can designate it's own class
>> loading mechanism.
>> Note that the methods take boolean verifyCodebaseIntegrity argument. I
>> think it could be replaced by placing constraints on a Module.
>>
>> 2. Before using a Module we prepare it using a ProxyPreparer - that way we
>> make sure we trust the Module before letting it load classes
>>
>> 3. We have a default implementation of Module that delegates class loading
>> to ClassLoading:
>> RmiModule implements Module {
>> private String annotation;
>> }
>>
>> 4. There is a single instance of RmiModule called BOOTSTRAP that we use to
>> load RmiModule class. This is implemented in:
>> RmiModule {
>> ...
>> static Module getModuleOf(final Class cl) {
>> /*
>> * RmiModule is equivalent of String annotation
>> * so it should be available locally
>> */
>> if (cl == RmiModule.class) {
>> return getBootstrap();
>> }
>>
>> final ClassLoader loader = getClassLoader(cl);
>> if (loader instanceof ModuleClassLoader) {
>> return ((ModuleClassLoader) loader).getModule();
>>
>> }
>>
>> final String annotation = RMIClassLoader.getClassAnnotation(cl);
>> return annotation != null ? RmiModule.getInstance(
>> annotation,getModuleTrust(loader)) : getBootstrap();
>> }
>> ...
>> }
>>
>> 5. We use the above method in annotateClass and annotateProxyClass of our
>> MarshalOutputStream
>>
>> 6. RmiModule can be verified by ProxyTrustVerifier. It's ProxyTrust
>> implementation delegates TrustVerifier retrieval to:
>> public interface ModuleAuthority extends Remote {
>> TrustVerifier getModuleVerifier() throws RemoteException;
>> }
>>
>> 7. We implement some helper functions that make it simpler to export a
>> service and provide its clients with either third party ModuleAuthority or
>> designate itself as a ModuleAuthority.
>>
>> 8. Before all this is implemented in PreferredClassProvider we have to
>> cache association between a ClassLoader and a Module. It's implemented in
>> RmiModule.
>>
>> 9. If we implement it in PreferredClassProvider our ClassLoaders can keep a
>> reference to associated Module
>>
>> 10. If we implement it in PreferredClassProvider we can have different
>> ClassLoaders for the same annotation but different ModuleAuthority - that
>> would actually allow us to grant permissions to Modules - before that two
>> different Modules with the same annotation are going to share permissions.
>>
>> I've attached a prototype implementation (note - it is a proto-proto-
>> prototype) so that you guys can verify if you have some spare time.
>> Don't know if mailing list server allows attachments.
>>
>> Michal
>>
>> On Tuesday 05 of October 2010 16:48:22 Michal Kleczek wrote:
>>
>>> On Tuesday 05 of October 2010 16:36:47 Gregg Wonderly wrote:
>>>
>>>> On 10/1/2010 12:38 PM, Michal Kleczek wrote:
>>>>
>>>>> When I think about it some more - the below idea is not enough and we
>>>>> need a more general solution.
>>>>> How about class annotation not being a String but rather an object...
>>>>> I have to give it some more thought.
>>>>>
>>>> There are been some thought and discussion about doing this. It is
>>>> possible, but the problem becomes that if you send an object with the
>>>> annotation, then how does the receiver unmarshall that object? Is that
>>>> object something that everyone knows about ahead of time?
>>>>
>>> My line of thought was - yes. It would have to be something similar to
>>> ProxyTrust - a factory to receive an Unmarshaller.
>>> I haven't really given it enough thought.
>>>
>>> But I am more and more convinced that doing that at the higher (proxy
>>> preparation) level - as I described it earlier - could actually be
>>> enough.
>>>
>>> Michal
>>>
>
>
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Some more thoughts.
There is one scenario that is not covered here:
I get an service, verify the module that loads its class using a
ModuleAuthority that I trust. This service in turn downloads some other
objects that it verified. There is no way I can delegate trust verification to
the service - I must trust Modules (actually ModuleAuthorities) of those
subsequent objects.
1. I have to have a way to allow or disallow module trust delegation (looks
like a case for dynamic permission grants)
2. This delegation has to be automatic (IOW the service does not have to do
anything - it is solely my decision to delegate)
Any ideas?
Michal
On Thursday 07 of October 2010 21:57:48 Michal Kleczek wrote:
> So...
> I've spent a day on some thinking and prototyping and hopefully I got an
> idea. Here is an outline:
>
> 1. We annotate classes with an object implementing Module interface:
> interface Module {
> //methods copied from ClassLoading but there is no annotation argument
> Class loadClass(...);
> Class loadProxyClass();
> }
> This makes class loading pluggable - a service can designate it's own class
> loading mechanism.
> Note that the methods take boolean verifyCodebaseIntegrity argument. I
> think it could be replaced by placing constraints on a Module.
>
> 2. Before using a Module we prepare it using a ProxyPreparer - that way we
> make sure we trust the Module before letting it load classes
>
> 3. We have a default implementation of Module that delegates class loading
> to ClassLoading:
> RmiModule implements Module {
> private String annotation;
> }
>
> 4. There is a single instance of RmiModule called BOOTSTRAP that we use to
> load RmiModule class. This is implemented in:
> RmiModule {
> ...
> static Module getModuleOf(final Class cl) {
> /*
> * RmiModule is equivalent of String annotation
> * so it should be available locally
> */
> if (cl == RmiModule.class) {
> return getBootstrap();
> }
>
> final ClassLoader loader = getClassLoader(cl);
> if (loader instanceof ModuleClassLoader) {
> return ((ModuleClassLoader) loader).getModule();
>
> }
>
> final String annotation = RMIClassLoader.getClassAnnotation(cl);
> return annotation != null ? RmiModule.getInstance(
> annotation,getModuleTrust(loader)) : getBootstrap();
> }
> ...
> }
>
> 5. We use the above method in annotateClass and annotateProxyClass of our
> MarshalOutputStream
>
> 6. RmiModule can be verified by ProxyTrustVerifier. It's ProxyTrust
> implementation delegates TrustVerifier retrieval to:
> public interface ModuleAuthority extends Remote {
> TrustVerifier getModuleVerifier() throws RemoteException;
> }
>
> 7. We implement some helper functions that make it simpler to export a
> service and provide its clients with either third party ModuleAuthority or
> designate itself as a ModuleAuthority.
>
> 8. Before all this is implemented in PreferredClassProvider we have to
> cache association between a ClassLoader and a Module. It's implemented in
> RmiModule.
>
> 9. If we implement it in PreferredClassProvider our ClassLoaders can keep a
> reference to associated Module
>
> 10. If we implement it in PreferredClassProvider we can have different
> ClassLoaders for the same annotation but different ModuleAuthority - that
> would actually allow us to grant permissions to Modules - before that two
> different Modules with the same annotation are going to share permissions.
>
> I've attached a prototype implementation (note - it is a proto-proto-
> prototype) so that you guys can verify if you have some spare time.
> Don't know if mailing list server allows attachments.
>
> Michal
>
> On Tuesday 05 of October 2010 16:48:22 Michal Kleczek wrote:
> > On Tuesday 05 of October 2010 16:36:47 Gregg Wonderly wrote:
> > > On 10/1/2010 12:38 PM, Michal Kleczek wrote:
> > > > When I think about it some more - the below idea is not enough and we
> > > > need a more general solution.
> > > > How about class annotation not being a String but rather an object...
> > > > I have to give it some more thought.
> > >
> > > There are been some thought and discussion about doing this. It is
> > > possible, but the problem becomes that if you send an object with the
> > > annotation, then how does the receiver unmarshall that object? Is that
> > > object something that everyone knows about ahead of time?
> >
> > My line of thought was - yes. It would have to be something similar to
> > ProxyTrust - a factory to receive an Unmarshaller.
> > I haven't really given it enough thought.
> >
> > But I am more and more convinced that doing that at the higher (proxy
> > preparation) level - as I described it earlier - could actually be
> > enough.
> >
> > Michal
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Friday 08 of October 2010 13:54:06 Sim IJskes - QCG wrote:
> On 10/08/2010 01:09 PM, Michal Kleczek wrote:
> > On Friday 08 of October 2010 13:02:17 Sim IJskes - QCG wrote:
> >> On 10/07/2010 09:57 PM, Michal Kleczek wrote:
> >>> So...
> >>> I've spent a day on some thinking and prototyping and hopefully I got
> >>> an idea. Here is an outline:
> >>
> >>> 1. We annotate classes with an object implementing Module interface:
> >> Is it safe to say that you are basically enhancing the codebase
> >> annotation pattern?
> >
> > Basically - yes.
> > Although I am not sure I understand precisely your question... :)
>
> You understood correctly. :-) (i should have said, construct, well ok).
>
> I noticed the readAnnotation of MarshallInputStream reads an Object and
> then casts it to a String. Are we sure that this is not a possible
> vector for a deserialization attack?
Looks like it is in current River.
> Personally i would have taken a
> UTF-8 String (with limited length), but if you only unmarshall Objects
> from TLS connections, that you check first, i guess its ok.
Right - in this solution we do not download any code before verifying we trust
the object (Module) that is going to download the code. In the basic scenario
we just contact the origin service and verify that the codebase string we got
is the right one.
One can imaging other ModuleAuthority implementations - for example requiring
that the codebase is digitally signed.
>
> So your solution is allowing for different credentials between the TLS
> and the code source, and checking these credentials.
>
> Is this package pluggable onto river without modifications in river?
I wouldn't call it "a package" :) At least not yet...
I think it can be made pluggable - I still have to resolve issues with
associating Modules with ClassLoaders - it would be soooo much easier to have
RmiClassLoder return Object from getClassAnnotation() and modify
ClassAnnotation to return a Module instead of String from getAnnotation().
Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/09/2010 05:20 AM, Peter Firmstone wrote:
>> Is this package pluggable onto river without modifications in river?
>
> Are you sure that's a good idea? Not modifying River I mean?
I have no problem with modifying river.
Gr. SIm
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 10/08/2010 01:09 PM, Michal Kleczek wrote:
>> On Friday 08 of October 2010 13:02:17 Sim IJskes - QCG wrote:
>>> On 10/07/2010 09:57 PM, Michal Kleczek wrote:
>>>> So...
>>>> I've spent a day on some thinking and prototyping and hopefully I
>>>> got an
>>>> idea. Here is an outline:
>>>
>>>> 1. We annotate classes with an object implementing Module interface:
>>> Is it safe to say that you are basically enhancing the codebase
>>> annotation pattern?
>> Basically - yes.
>> Although I am not sure I understand precisely your question... :)
>
> You understood correctly. :-) (i should have said, construct, well ok).
>
> I noticed the readAnnotation of MarshallInputStream reads an Object
> and then casts it to a String. Are we sure that this is not a possible
> vector for a deserialization attack? Personally i would have taken a
> UTF-8 String (with limited length), but if you only unmarshall Objects
> from TLS connections, that you check first, i guess its ok.
>
> So your solution is allowing for different credentials between the TLS
> and the code source, and checking these credentials.
>
> Is this package pluggable onto river without modifications in river?
Are you sure that's a good idea? Not modifying River I mean?
Michal's given this issue some thought.
It appears to solve the following problems:
1. CodeSource identity is no longer based on it's originating URL
location.
2. Two services using the same proxy CodeSource don't share the same
ClassLoader, one service can't gain the privileges of the other.
I'd had some thoughts about using Subject's in ClassLoader's with
Identical CodeSource for distinct identity, however the Subject isn't
known until after the classes are loaded.
I think we need to set up an issue on Jira and in skunk where we can
collaborate and explore further development.
Something I'd like to further explore is a ClassLoader inheritance
structure that places Service API and Jini Platform classes in a Parent
ClassLoader and all application, service and proxy classes in child
ClassLoaders, so they're forced to cooperate using the Service API, Jini
and Java Platform classes. This also ensures implementation classes
aren't visible to proxy code, for good security.
Cheers,
Peter.
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/08/2010 01:09 PM, Michal Kleczek wrote:
> On Friday 08 of October 2010 13:02:17 Sim IJskes - QCG wrote:
>> On 10/07/2010 09:57 PM, Michal Kleczek wrote:
>>> So...
>>> I've spent a day on some thinking and prototyping and hopefully I got an
>>> idea. Here is an outline:
>>
>>> 1. We annotate classes with an object implementing Module interface:
>> Is it safe to say that you are basically enhancing the codebase
>> annotation pattern?
> Basically - yes.
> Although I am not sure I understand precisely your question... :)
You understood correctly. :-) (i should have said, construct, well ok).
I noticed the readAnnotation of MarshallInputStream reads an Object and
then casts it to a String. Are we sure that this is not a possible
vector for a deserialization attack? Personally i would have taken a
UTF-8 String (with limited length), but if you only unmarshall Objects
from TLS connections, that you check first, i guess its ok.
So your solution is allowing for different credentials between the TLS
and the code source, and checking these credentials.
Is this package pluggable onto river without modifications in river?
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Friday 08 of October 2010 13:02:17 Sim IJskes - QCG wrote:
> On 10/07/2010 09:57 PM, Michal Kleczek wrote:
> > So...
> > I've spent a day on some thinking and prototyping and hopefully I got an
> > idea. Here is an outline:
>
> > 1. We annotate classes with an object implementing Module interface:
> Is it safe to say that you are basically enhancing the codebase
> annotation pattern?
Basically - yes.
Although I am not sure I understand precisely your question... :)
Michal
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Thursday 07 of October 2010 21:57:48 Michal Kleczek wrote:
> 8. Before all this is implemented in PreferredClassProvider we have to
> cache association between a ClassLoader and a Module. It's implemented in
> RmiModule.
>
> 9. If we implement it in PreferredClassProvider our ClassLoaders can keep a
> reference to associated Module
>
> 10. If we implement it in PreferredClassProvider we can have different
> ClassLoaders for the same annotation but different ModuleAuthority - that
> would actually allow us to grant permissions to Modules - before that two
> different Modules with the same annotation are going to share permissions.
I think a hack to actually force a different ClassLoader for each unique
RmiModule is to simply append a "dummy" randomly generated URL to the codebase
annotation when loading classes using RMIClassLoader.
Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/07/2010 09:57 PM, Michal Kleczek wrote:
> So...
> I've spent a day on some thinking and prototyping and hopefully I got an idea.
> Here is an outline:
>
> 1. We annotate classes with an object implementing Module interface:
Is it safe to say that you are basically enhancing the codebase
annotation pattern?
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Gregg Wonderly wrote:
> On 10/9/2010 4:10 AM, Sim IJskes - QCG wrote:
>> We can have a URL handler for downloading code over any medium. We
>> could enforce
>> only downloading code over trusted endpoints.
>>
>> Once we have the jar in the localvm, we can verify the codesigning of
>> the
>> classes. The only thing we need to do is to enrich the information
>> passed to
>> verifyIntegrity() from codebase to code.
>>
>> [or we could just have a caching url handler, and retrieve the code
>> again (but
>> this time from the cache) in a IntegrityVerifier. This would change
>> nothing in
>> the current river code. Any worms in this can?]
>
> To reiterate what I've been using for my desktop clients policy
> management...
>
> I have two files full of lines of text. One is a list of host names,
> the other is a list of URL suffixes.
>
> hosts.txt:
> hosta.here.com
> hostb.here.com
> hosta.there.com
>
> urls.txt:
> 8090/reggie-dl.jar
> 8090/mahalo-dl.jar
> 8080/utils.jar
> 8080/otherutils.jar
>
> I have a URL handler which is a caching handler so that jars can be
> loaded from disk. It always does a HEAD and checks date and size to
> be the same. If missing, or out of date, it is downloaded.
>
> I use a Codesource grant on all host:url combinations of AllPermission.
In the new RevokeableDynamicPolicy, I've made it possible to perform
dynamic grant's to CodeSource, so you don't need to define Codesource
grant's in files anymore, they can be delayed until required, you no
longer need to know the CodeSource in advance.
Same goes for Certificate[] grants.
>
> One simple side effect of this handler, is that if I have a test
> machine that I am setting up that is not production, the users see it,
> but until they add the host to their hosts.txt, all code downloads
> fail with file create/write permission checks on the caching handler.
> So, they can't access the test services by mistake. They will see an
> exception message about the file access.
>
> Clearly, a purposeful attack, can provide urls that don't go through
> my handler, and get to the deserialization attack already mentioned (I
> ranted about this for some time many years ago, trying to see if I
> could get Sun to own up to it, and fix it). Requiring download
> permission can mediate some of this in the endpoint.
It should be possible to create a Security Delegate SocketFactory that
produce download limiting Sockets (or upload limited). Your given a
download limit, once you exceed it, permission to obtain new Sockets is
revoked and all existing InputStreams are closed on the next
invocation. The Sockets could be leased as well, so they can be cleaned
up if the caller doesn't close them or renew it's lease, (it would need
the permission to renew it's lease).
In this case the permission would be
DelegatePermission(SocketPermission) and Li Gong's Object Method Guard
pattern would be used.
Cheers,
Peter
Re: Towards Internet Jini Services (trust)
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 10/9/2010 4:10 AM, Sim IJskes - QCG wrote:
> We can have a URL handler for downloading code over any medium. We could enforce
> only downloading code over trusted endpoints.
>
> Once we have the jar in the localvm, we can verify the codesigning of the
> classes. The only thing we need to do is to enrich the information passed to
> verifyIntegrity() from codebase to code.
>
> [or we could just have a caching url handler, and retrieve the code again (but
> this time from the cache) in a IntegrityVerifier. This would change nothing in
> the current river code. Any worms in this can?]
To reiterate what I've been using for my desktop clients policy management...
I have two files full of lines of text. One is a list of host names, the other
is a list of URL suffixes.
hosts.txt:
hosta.here.com
hostb.here.com
hosta.there.com
urls.txt:
8090/reggie-dl.jar
8090/mahalo-dl.jar
8080/utils.jar
8080/otherutils.jar
I have a URL handler which is a caching handler so that jars can be loaded from
disk. It always does a HEAD and checks date and size to be the same. If
missing, or out of date, it is downloaded.
I use a Codesource grant on all host:url combinations of AllPermission.
One simple side effect of this handler, is that if I have a test machine that I
am setting up that is not production, the users see it, but until they add the
host to their hosts.txt, all code downloads fail with file create/write
permission checks on the caching handler. So, they can't access the test
services by mistake. They will see an exception message about the file access.
Clearly, a purposeful attack, can provide urls that don't go through my handler,
and get to the deserialization attack already mentioned (I ranted about this for
some time many years ago, trying to see if I could get Sun to own up to it, and
fix it). Requiring download permission can mediate some of this in the endpoint.
Gregg Wonderly
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/07/2010 09:57 PM, Michal Kleczek wrote:
> 1. We annotate classes with an object implementing Module interface:
> interface Module {
> //methods copied from ClassLoading but there is no annotation argument
> Class loadClass(...);
> Class loadProxyClass();
> }
> This makes class loading pluggable - a service can designate it's own class
> loading mechanism.
> Note that the methods take boolean verifyCodebaseIntegrity argument. I think
> it could be replaced by placing constraints on a Module.
I still need some convincing on providing remote classloaders.
Wouldn't we solve the problem 'trust by signing code', by modifying
ClassLoading.loadClass()?
We can have a URL handler for downloading code over any medium. We could
enforce only downloading code over trusted endpoints.
Once we have the jar in the localvm, we can verify the codesigning of
the classes. The only thing we need to do is to enrich the information
passed to verifyIntegrity() from codebase to code.
[or we could just have a caching url handler, and retrieve the code
again (but this time from the cache) in a IntegrityVerifier. This would
change nothing in the current river code. Any worms in this can?]
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 10/07/2010 09:57 PM, Michal Kleczek wrote:
>> 1. We annotate classes with an object implementing Module interface:
>> interface Module {
>> //methods copied from ClassLoading but there is no annotation
>> argument
>> Class loadClass(...);
>> Class loadProxyClass();
>> }
> > This makes class loading pluggable - a service can designate it's
> own class
> > loading mechanism.
>
> By changing the annotation from a final class into a interface, you
> have created another deployment issue. Code containing the
> implementation should already be accessible by the local classloader.
>
> Lets keep it a String.
>
> Gr. Sim
>
The bootstrap RMIModule is for that purpose, let's give Michal some more
time to demonstrate it, if it eliminates the DOS hole then that's good
enough for me.
Cheers,
Peter.
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/07/2010 09:57 PM, Michal Kleczek wrote:
> 1. We annotate classes with an object implementing Module interface:
> interface Module {
> //methods copied from ClassLoading but there is no annotation argument
> Class loadClass(...);
> Class loadProxyClass();
> }
> This makes class loading pluggable - a service can designate it's own
class
> loading mechanism.
By changing the annotation from a final class into a interface, you have
created another deployment issue. Code containing the implementation
should already be accessible by the local classloader.
Lets keep it a String.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
So...
I've spent a day on some thinking and prototyping and hopefully I got an idea.
Here is an outline:
1. We annotate classes with an object implementing Module interface:
interface Module {
//methods copied from ClassLoading but there is no annotation argument
Class loadClass(...);
Class loadProxyClass();
}
This makes class loading pluggable - a service can designate it's own class
loading mechanism.
Note that the methods take boolean verifyCodebaseIntegrity argument. I think
it could be replaced by placing constraints on a Module.
2. Before using a Module we prepare it using a ProxyPreparer - that way we
make sure we trust the Module before letting it load classes
3. We have a default implementation of Module that delegates class loading to
ClassLoading:
RmiModule implements Module {
private String annotation;
}
4. There is a single instance of RmiModule called BOOTSTRAP that we use to
load RmiModule class. This is implemented in:
RmiModule {
...
static Module getModuleOf(final Class cl) {
/*
* RmiModule is equivalent of String annotation
* so it should be available locally
*/
if (cl == RmiModule.class) {
return getBootstrap();
}
final ClassLoader loader = getClassLoader(cl);
if (loader instanceof ModuleClassLoader) {
return ((ModuleClassLoader) loader).getModule();
}
final String annotation = RMIClassLoader.getClassAnnotation(cl);
return annotation != null ? RmiModule.getInstance(
annotation,getModuleTrust(loader)) : getBootstrap();
}
...
}
5. We use the above method in annotateClass and annotateProxyClass of our
MarshalOutputStream
6. RmiModule can be verified by ProxyTrustVerifier. It's ProxyTrust
implementation delegates TrustVerifier retrieval to:
public interface ModuleAuthority extends Remote {
TrustVerifier getModuleVerifier() throws RemoteException;
}
7. We implement some helper functions that make it simpler to export a service
and provide its clients with either third party ModuleAuthority or designate
itself as a ModuleAuthority.
8. Before all this is implemented in PreferredClassProvider we have to cache
association between a ClassLoader and a Module. It's implemented in RmiModule.
9. If we implement it in PreferredClassProvider our ClassLoaders can keep a
reference to associated Module
10. If we implement it in PreferredClassProvider we can have different
ClassLoaders for the same annotation but different ModuleAuthority - that would
actually allow us to grant permissions to Modules - before that two different
Modules with the same annotation are going to share permissions.
I've attached a prototype implementation (note - it is a proto-proto-
prototype) so that you guys can verify if you have some spare time.
Don't know if mailing list server allows attachments.
Michal
On Tuesday 05 of October 2010 16:48:22 Michal Kleczek wrote:
> On Tuesday 05 of October 2010 16:36:47 Gregg Wonderly wrote:
> > On 10/1/2010 12:38 PM, Michal Kleczek wrote:
> > > When I think about it some more - the below idea is not enough and we
> > > need a more general solution.
> > > How about class annotation not being a String but rather an object... I
> > > have to give it some more thought.
> >
> > There are been some thought and discussion about doing this. It is
> > possible, but the problem becomes that if you send an object with the
> > annotation, then how does the receiver unmarshall that object? Is that
> > object something that everyone knows about ahead of time?
>
> My line of thought was - yes. It would have to be something similar to
> ProxyTrust - a factory to receive an Unmarshaller.
> I haven't really given it enough thought.
>
> But I am more and more convinced that doing that at the higher (proxy
> preparation) level - as I described it earlier - could actually be enough.
>
> Michal
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 05 of October 2010 16:36:47 Gregg Wonderly wrote:
> On 10/1/2010 12:38 PM, Michal Kleczek wrote:
> > When I think about it some more - the below idea is not enough and we
> > need a more general solution.
> > How about class annotation not being a String but rather an object... I
> > have to give it some more thought.
>
> There are been some thought and discussion about doing this. It is
> possible, but the problem becomes that if you send an object with the
> annotation, then how does the receiver unmarshall that object? Is that
> object something that everyone knows about ahead of time?
My line of thought was - yes. It would have to be something similar to
ProxyTrust - a factory to receive an Unmarshaller.
I haven't really given it enough thought.
But I am more and more convinced that doing that at the higher (proxy
preparation) level - as I described it earlier - could actually be enough.
Michal
Re: Towards Internet Jini Services (trust)
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 10/1/2010 12:38 PM, Michal Kleczek wrote:
> When I think about it some more - the below idea is not enough and we need a
> more general solution.
> How about class annotation not being a String but rather an object... I have
> to give it some more thought.
There are been some thought and discussion about doing this. It is possible,
but the problem becomes that if you send an object with the annotation, then how
does the receiver unmarshall that object? Is that object something that
everyone knows about ahead of time?
Gregg Wonderly
> Michal
>
> On Friday 01 of October 2010 15:00:49 Michal Kleczek wrote:
>> Folks,
>> I'm reading this thread with a lot of interest and wanted to throw my 2
>> cents.
>>
>> 1. I think we should stop talking about "services" and "service registrars"
>> when talking about downloading code - RemoteEventListener can be a smart
>> proxy too...
>>
>> 2. Java permissioning model is enough to trust that code will not do
>> anything bad like read my bank account credentials. Of course we cannot
>> check that the code does not have any bugs - we cannot solve halting
>> problem anyway...
>>
>> 3. I agree with Tom that making sure the code comes from a known source is
>> enough to make a decision whether to run this code or not. But Jini already
>> checks that (well... almost)- the only hole is that the check is done
>> _after_ deserialization - so it means the code was executed _before_ the
>> check was done. My question actually is - why don't we check an object
>> before it is deserialized?
>>
>> My idea would be as follows:
>> a) _Never_ download code when deserializing data (objects) comming from the
>> network (IOW MarshalledInputStream should behave like ObjectInputStream -
>> use TCCL to load classes)
>>
>> b) when sending a proxy wrap it in a dynamic proxy with invocation handler
>> that has two objects: a ProxyTrust and a marshalled real proxy
>>
>> c) upon receiving of a (smart) proxy prepare it using a preparer that wraps
>> original proxy with the one that makes sure TCCL is set apropriatelly for
>> each method invocation - this is necessary so that deserialization of
>> subsequent objects received by the proxy is successful (see point a).
>> The preparer would check if it is preparing the proxy with
>> TrustedInvocationHandler, then verifiy trust using std. Jini trust
>> verification, then retrieve the real proxy, get it's ClassLoader and
>> return a TCCL setting proxy wrapping it..
>>
>> Some code:
>>
>> //returned by remote service
>> //cannot deserialize passed instance before actually making the check
>> //it is not a problem for the client because it is obtained from a trusted
>> //ProxyTrust implementation
>> interface MarshalledInstanceVerifier {
>> boolean isTrustedMarshalledInstance(MarshalledInstance<?> instance);
>> }
>>
>> class TrustedInvocationHandler implements InvocationHandler {
>> private MarshalledInstance<?> realProxy;
>> private ProxyTrust proxyTrust;
>>
>> Object getRealProxy() {
>> return realProxy.get();
>> }
>>
>> ClassLoader getRealProxyClassLoader() {
>> return getRealProxy().getClassLoader();
>> }
>>
>> protected ProxyTrustIterator getProxyTrustIterator() {
>> return new SingletonProxyTrustIterator(proxyTrust);
>> }
>> }
>>
>> class TrustedInvocationHandlerVerifier implements TrustVerifier {
>> private MarshalledInstanceVerifier delegate;
>> public boolean isTrustedObject(Object o, TrustVerifier.Context ctx) {
>> //check that o is a proxy with TrustedInvocationHandler
>> //...
>> TrustedInvocationHandler handler = ...
>> return delegate.isTrustedMarshalledInstance(handler.realProxy);
>> }
>> }
>>
>> What do you think?
>>
>> Michal
>>
>> On Friday 01 of October 2010 14:05:51 Zoltan Juhasz wrote:
>>> Tom and all,
>>>
>>>> When was the last time you analysed the contents of your
>>>> newly downloaded log4j.jar, just to make sure it didn't
>>>> contain anything nasty? In that example, you trusted the
>>>> download site (apache.org), and you trusted the download
>>>> mechanism (HTTP - now that was risky!), and then you trusted
>>>> the stuff you downloaded.
>>>
>>> I think this is a key observation. The Jini mechanism for trust is based
>>> on trusting the source and the download channel but that does not imply
>>> anything about the quality of the code you're about to execute. When you
>>> download anything manually (in your browser), you have time to decide
>>> whether or not you take the risk. Jini however is about programmatic
>>> clients doing this automatically without human intervention. The speed
>>> of execution is at a different scale. One would need semantic
>>> correctness checks which is impossible to do right now. We had bumped
>>> into this problem when we used Jini for distributed/parallel computation
>>> and the only solution we could come up was to have accountability and a
>>> mechanism for non-repudiation, ie you code can do stupid things but I'll
>>> catch you and make you pay for it.
>>>
>>> I don't know whether there is a universal solution to this, it is a very
>>> complicated problem.
>>>
>>>
>>>
>>>
>>> Zoltan
>
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/01/2010 07:38 PM, Michal Kleczek wrote:
>> My idea would be as follows:
>> a) _Never_ download code when deserializing data (objects) comming from the
>> network (IOW MarshalledInputStream should behave like ObjectInputStream -
>> use TCCL to load classes)
We need a "do not download" default and optional download permission.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mk...@contour-technology.com>.
When I think about it some more - the below idea is not enough and we need a
more general solution.
How about class annotation not being a String but rather an object... I have
to give it some more thought.
Michal
On Friday 01 of October 2010 15:00:49 Michal Kleczek wrote:
> Folks,
> I'm reading this thread with a lot of interest and wanted to throw my 2
> cents.
>
> 1. I think we should stop talking about "services" and "service registrars"
> when talking about downloading code - RemoteEventListener can be a smart
> proxy too...
>
> 2. Java permissioning model is enough to trust that code will not do
> anything bad like read my bank account credentials. Of course we cannot
> check that the code does not have any bugs - we cannot solve halting
> problem anyway...
>
> 3. I agree with Tom that making sure the code comes from a known source is
> enough to make a decision whether to run this code or not. But Jini already
> checks that (well... almost)- the only hole is that the check is done
> _after_ deserialization - so it means the code was executed _before_ the
> check was done. My question actually is - why don't we check an object
> before it is deserialized?
>
> My idea would be as follows:
> a) _Never_ download code when deserializing data (objects) comming from the
> network (IOW MarshalledInputStream should behave like ObjectInputStream -
> use TCCL to load classes)
>
> b) when sending a proxy wrap it in a dynamic proxy with invocation handler
> that has two objects: a ProxyTrust and a marshalled real proxy
>
> c) upon receiving of a (smart) proxy prepare it using a preparer that wraps
> original proxy with the one that makes sure TCCL is set apropriatelly for
> each method invocation - this is necessary so that deserialization of
> subsequent objects received by the proxy is successful (see point a).
> The preparer would check if it is preparing the proxy with
> TrustedInvocationHandler, then verifiy trust using std. Jini trust
> verification, then retrieve the real proxy, get it's ClassLoader and
> return a TCCL setting proxy wrapping it..
>
> Some code:
>
> //returned by remote service
> //cannot deserialize passed instance before actually making the check
> //it is not a problem for the client because it is obtained from a trusted
> //ProxyTrust implementation
> interface MarshalledInstanceVerifier {
> boolean isTrustedMarshalledInstance(MarshalledInstance<?> instance);
> }
>
> class TrustedInvocationHandler implements InvocationHandler {
> private MarshalledInstance<?> realProxy;
> private ProxyTrust proxyTrust;
>
> Object getRealProxy() {
> return realProxy.get();
> }
>
> ClassLoader getRealProxyClassLoader() {
> return getRealProxy().getClassLoader();
> }
>
> protected ProxyTrustIterator getProxyTrustIterator() {
> return new SingletonProxyTrustIterator(proxyTrust);
> }
> }
>
> class TrustedInvocationHandlerVerifier implements TrustVerifier {
> private MarshalledInstanceVerifier delegate;
> public boolean isTrustedObject(Object o, TrustVerifier.Context ctx) {
> //check that o is a proxy with TrustedInvocationHandler
> //...
> TrustedInvocationHandler handler = ...
> return delegate.isTrustedMarshalledInstance(handler.realProxy);
> }
> }
>
> What do you think?
>
> Michal
>
> On Friday 01 of October 2010 14:05:51 Zoltan Juhasz wrote:
> > Tom and all,
> >
> > > When was the last time you analysed the contents of your
> > > newly downloaded log4j.jar, just to make sure it didn't
> > > contain anything nasty? In that example, you trusted the
> > > download site (apache.org), and you trusted the download
> > > mechanism (HTTP - now that was risky!), and then you trusted
> > > the stuff you downloaded.
> >
> > I think this is a key observation. The Jini mechanism for trust is based
> > on trusting the source and the download channel but that does not imply
> > anything about the quality of the code you're about to execute. When you
> > download anything manually (in your browser), you have time to decide
> > whether or not you take the risk. Jini however is about programmatic
> > clients doing this automatically without human intervention. The speed
> > of execution is at a different scale. One would need semantic
> > correctness checks which is impossible to do right now. We had bumped
> > into this problem when we used Jini for distributed/parallel computation
> > and the only solution we could come up was to have accountability and a
> > mechanism for non-repudiation, ie you code can do stupid things but I'll
> > catch you and make you pay for it.
> >
> > I don't know whether there is a universal solution to this, it is a very
> > complicated problem.
> >
> >
> >
> >
> > Zoltan
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/05/2010 04:07 PM, Mike McGrady wrote:
> Nice!
Paris!
Re: Towards Internet Jini Services (trust)
Posted by Mike McGrady <mm...@topiatechnology.com>.
Nice!
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Oct 5, 2010, at 6:36 AM, Michal Kleczek <mi...@xpro.biz> wrote:
> Looks like the real underlying issue in understanding is the definition of the
> Jini Platform.
>
> How I see it is: the platform is the _minimal_ set of software that I need to
> manually install on my computer to safely exchange objects (code + data) with
> other computers and run the code that constitutes those objects.
>
> Everything else should be implemented as a service (an object) that is run on
> top of the platform - and should not be considered a part of the platform.
> I would even say it should be discussed if discovery protocols and
> ServiceRegistrar definition are part of the platform.
>
> So what do we have now?
> JVM - necessary to have dynamic code downloading and permissions
> PreferredClassProvider and PreferredClassLoader - necessary to deal with
> codebase issues
> IntegrityVerifier interface, httpmd url handler and HttpmdIntegrityVerifier -
> necessary to make sure we download the right code to unmarshal an object (BTW
> - are there any fundamental security issues with having other
> UrlStreamHandlers and IntegrityVerifiers provided as services - similarly to
> how OSGI does that?)
> TrustVerifier, ProxyTrust, RemoteMethodControl, Constraint, ProxyPreparer
> interfaces and their basic implementations - necessary to verify unmarshalled
> objects
> various JERI endpoint implementations - necessary to be able to implement
> ProxyTrust (BTW should unsecure endpoints like TcpEndpoint _really_ be part of
> the platform?)
>
> As I see it - if we close the gap and solve the issue of possible DoS during
> deserialization we have a complete platform to build everything else as
> services on top of it.
> Even complicated trust decisions can be made by delegating to trusted
> services.
> We can quite easily build "sandbox" services (for example on top of Phoenix)
> so that the client can choose not to download any code into it's own address
> space.
>
> What am I missing?
>
> Michal
>
>
> On Tuesday 05 of October 2010 13:07:35 Peter Firmstone wrote:
>> Yes I think Sim is talking about making trust decisions and Michal and I
>> are talking about the handshake, we need both, I don't think we're
>> having an issue of agreement, just understanding.
>>
>> I'd like to see some kind of feedback service, where you give a good
>> rating when you get a good service and a bad one when you don't. I'd
>> also like to see a security advisory service, for handling discovered
>> vulnerabilities. These things might be useful in making trust decisions.
>>
>> I'd also like some trust levels defined, with a wider range of
>> permissions as trust increases. But I'd only like to grant the
>> intersection of the trust level Set of Permissions and the Set requested.
>>
>> I'd like to see the level of trust others are granting to a service via
>> feedback services, if a service misbehaves and it's caught out, the
>> level of trust will diminish.
>>
>> Then we can go with the crowd, safety in numbers, like a school of fish,
>> just don't get caught in a bait ball.
>>
>> Cheers,
>>
>> Peter.
>>
>> Michal Kleczek wrote:
>>> Of course - I am not talking about the problem of deciding whether I
>>> should trust a particular service - this is a completely different
>>> subject and I am not really sure if we should even try to solve it since
>>> I don't think it is possible to do without human intervention. In the
>>> end - choosing to trust and use gmail versus yahoo is not something that
>>> can be done automatically.
>>>
>>> But checking whether an object (code + data) comes from the service I
>>> trust is something that can be done and is a prerequisite to the above
>>> anyway.
>>>
>>> Michal
>>>
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Looks like the real underlying issue in understanding is the definition of the
Jini Platform.
How I see it is: the platform is the _minimal_ set of software that I need to
manually install on my computer to safely exchange objects (code + data) with
other computers and run the code that constitutes those objects.
Everything else should be implemented as a service (an object) that is run on
top of the platform - and should not be considered a part of the platform.
I would even say it should be discussed if discovery protocols and
ServiceRegistrar definition are part of the platform.
So what do we have now?
JVM - necessary to have dynamic code downloading and permissions
PreferredClassProvider and PreferredClassLoader - necessary to deal with
codebase issues
IntegrityVerifier interface, httpmd url handler and HttpmdIntegrityVerifier -
necessary to make sure we download the right code to unmarshal an object (BTW
- are there any fundamental security issues with having other
UrlStreamHandlers and IntegrityVerifiers provided as services - similarly to
how OSGI does that?)
TrustVerifier, ProxyTrust, RemoteMethodControl, Constraint, ProxyPreparer
interfaces and their basic implementations - necessary to verify unmarshalled
objects
various JERI endpoint implementations - necessary to be able to implement
ProxyTrust (BTW should unsecure endpoints like TcpEndpoint _really_ be part of
the platform?)
As I see it - if we close the gap and solve the issue of possible DoS during
deserialization we have a complete platform to build everything else as
services on top of it.
Even complicated trust decisions can be made by delegating to trusted
services.
We can quite easily build "sandbox" services (for example on top of Phoenix)
so that the client can choose not to download any code into it's own address
space.
What am I missing?
Michal
On Tuesday 05 of October 2010 13:07:35 Peter Firmstone wrote:
> Yes I think Sim is talking about making trust decisions and Michal and I
> are talking about the handshake, we need both, I don't think we're
> having an issue of agreement, just understanding.
>
> I'd like to see some kind of feedback service, where you give a good
> rating when you get a good service and a bad one when you don't. I'd
> also like to see a security advisory service, for handling discovered
> vulnerabilities. These things might be useful in making trust decisions.
>
> I'd also like some trust levels defined, with a wider range of
> permissions as trust increases. But I'd only like to grant the
> intersection of the trust level Set of Permissions and the Set requested.
>
> I'd like to see the level of trust others are granting to a service via
> feedback services, if a service misbehaves and it's caught out, the
> level of trust will diminish.
>
> Then we can go with the crowd, safety in numbers, like a school of fish,
> just don't get caught in a bait ball.
>
> Cheers,
>
> Peter.
>
> Michal Kleczek wrote:
> > Of course - I am not talking about the problem of deciding whether I
> > should trust a particular service - this is a completely different
> > subject and I am not really sure if we should even try to solve it since
> > I don't think it is possible to do without human intervention. In the
> > end - choosing to trust and use gmail versus yahoo is not something that
> > can be done automatically.
> >
> > But checking whether an object (code + data) comes from the service I
> > trust is something that can be done and is a prerequisite to the above
> > anyway.
> >
> > Michal
> >
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 10/05/2010 03:45 PM, Michal Kleczek wrote:
>> What I am trying to get at is - could this be implemented as a
>> service on top
>> of existing Jini platform?
>
> Do you have a solution for the unmarshalling of untrusted code yet?
>
> Gr. Sim
>
Have a look in jtsk/skunk/pepe under org.apache.river.imp.security.dos.
I could use a volunteer to write some test cases and code review. It's
very preliminary at this stage, I've uploaded it to get the concept out
there.
I need the following Unmarshalling Attack test cases and any others you
might think of:
1. Infinite Loop.
2. Object Creation explosion, using an Array or List.
3. Deliberate thread stalling or concurrency issues.
Assume the object byte arrays have been downloaded directly over a
secure socket with privacy intact.
Regards,
Peter.
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/05/2010 03:45 PM, Michal Kleczek wrote:
> What I am trying to get at is - could this be implemented as a service on top
> of existing Jini platform?
Do you have a solution for the unmarshalling of untrusted code yet?
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Tuesday 05 of October 2010 14:56:42 Sim IJskes - QCG wrote:
> On 10/05/2010 01:52 PM, Michal Kleczek wrote:
> > 2. I am not sure either whether principal based trust decisions is not
> > enough as a basis for certification friendliness - isn't it just a
> > matter of either: a) dynamic retrieval of certified principals from a
> > trusted certification service
>
> Just to make it clear. I'm not talking about certification of
> principals, i'm talking about certification of software baselines.
>
What I am trying to get at is - could this be implemented as a service on top
of existing Jini platform?
Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/05/2010 02:56 PM, Sim IJskes - QCG wrote:
> On 10/05/2010 01:52 PM, Michal Kleczek wrote:
>> 2. I am not sure either whether principal based trust decisions is not
>> enough
>> as a basis for certification friendliness - isn't it just a matter of
>> either:
>> a) dynamic retrieval of certified principals from a trusted certification
>> service
>
> Just to make it clear. I'm not talking about certification of
> principals, i'm talking about certification of software baselines.
Would it be a option to add a method:
net.jini.security.Security.verifyCodebaseIntegrity(CodeSource cs,
ClassLoader cl)
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/05/2010 01:52 PM, Michal Kleczek wrote:
> 2. I am not sure either whether principal based trust decisions is not enough
> as a basis for certification friendliness - isn't it just a matter of either:
> a) dynamic retrieval of certified principals from a trusted certification
> service
Just to make it clear. I'm not talking about certification of
principals, i'm talking about certification of software baselines.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Hmm...
1. I am not really sure if you need to mess with classloader to achieve that.
Wouldn't something I proposed earlier allow you to postpone unmarshalling to
after you made your trust decision?
2. I am not sure either whether principal based trust decisions is not enough
as a basis for certification friendliness - isn't it just a matter of either:
a) dynamic retrieval of certified principals from a trusted certification
service
b) in its simplest form just require the service to authenticate and rely on
authentication mechanism to keep track of certified principals (IOW x509
certificates get revoked or kerberos principals removed from KDC)
c) require ProxyTrust to authenticate not as a target service principal but as
a certifying authority principal - IOW proxy verification is not implemented by
the service itself but rather delegated by the service to a third party.
Michal
On Tuesday 05 of October 2010 13:27:50 Sim IJskes - QCG wrote:
> On 10/05/2010 01:07 PM, Peter Firmstone wrote:
> > Yes I think Sim is talking about making trust decisions and Michal and I
> > are talking about the handshake, we need both, I don't think we're
> > having an issue of agreement, just understanding.
>
> No, i'm talking about both.
>
> Before you can unmarshall, you need code. This code is loaded by a
> classloader. The ONLY place where we can check code, is this classloader.
>
> For every trust decision i've made, the classloader should check if what
> is loaded is consistent with the trust decision i've made.
>
> I want this trust system to be exclusive. Only when trust is granted am
> i willing to perform code i have been given.
>
> I want this trust system to be dynamic. I want to be able to change my
> mind.
>
> I want this trust system to be automated only in removing trust. I dont
> want to have a machine surprise me by downloading a trojan.
>
> I want this system to be certification friendly. So not only based on
> Principal alone.
>
> Eh, would this constitute a requirements definition? :-)
>
> Gr. Sim
Re: webstart signed jars
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/07/2010 11:14 AM, Sim IJskes - QCG wrote:
> All the classes that were seen during webstart deployment, where true
> proxies [Proxy.isProxy(obj) == true].
Before somebody complains: Proxy.isProxyClass(cls) == true. :-|
Re: webstart signed jars
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/07/2010 10:23 AM, Sim IJskes - QCG wrote:
> Some bad news here, i'm afraid. I did a quick inventory of the classes
> passed through a TrustVerfifier, and it turns out that if you deploy via
> webstart with signed jars, the classloader does not fill in the
> CodeSource of the ProtectionDomain. I'm not sure what this means for
Ignore this.
All the classes that were seen during webstart deployment, where true
proxies [Proxy.isProxy(obj) == true].
Started from the commandline classes like
net.jini.jeri.BasicObjectEndpoint, net.jini.jeri.tcp.TcpEndpoint were
also passed through the TrustVerifier.
Gr. Sim
webstart signed jars
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/07/2010 08:57 AM, Peter Firmstone wrote:
> Firstly let me say that I like your idea, a feature requiring a jar file
> be signed by a known Certificate, before allowing class loading, I'd
> like to implement it together, if your interested. This would provide
> good security for parties already known to each other.
Some bad news here, i'm afraid. I did a quick inventory of the classes
passed through a TrustVerfifier, and it turns out that if you deploy via
webstart with signed jars, the classloader does not fill in the
CodeSource of the ProtectionDomain. I'm not sure what this means for
other verification mechanisms, based on CodeSource. I'm not sure either
what kind of hole we open, if we assume codeSource == null means loaded
via the local classloader. The normal classloader used when the VM is
invoked from the commandline, provides all classes with codesources. So
why webstart doesn't is a mystery to me.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Sim IJskes - QCG wrote:
>> On 10/06/2010 02:58 AM, Peter Firmstone wrote:
>>>> I want this trust system to be dynamic. I want to be able to change my
>>>> mind.
>>>
>>> Once you've loaded the class files, that's it, the ClassLoader will
>>> only
>>> become garbage collected when no strong references to objects and class
>>> files remain. You've only got one shot at that decision.
>>
>> Thats too much black and white for me. I was talking about multiple
>> invocations of a VM. So that means remembering trust decisions.
>
> That makes sense, perhaps you can share the trust decision and the
> result of that decision by submitting it to a feedback service, your
> VM could send this information before shutting down.
>
>>
>> I we have misbehaving code, we cannot stop it easily. So that means
>> changing the trustlevel, and restarting the VM (no specific order).
>
> Have you got any thoughts on trust levels?
>
>
>> Or are you willing to use Thread.stop()?
>>
>>
> No, first implement an UncaughtExceptionHandler, use it with a Single
> threaded ExecutorService, also create a ThreadFactory that creates a
> Thread utilising the UncaughtExceptionHandler.
>
> This catches a StackOverflowError, we still need strategies for other
> Errors. Instead of using Runnable, Callable is used so that the
> method calls from the reflective proxy return any Exceptions, these
> can be wrapped in an IOException for the client to handle.
>
> Since the thread is a low priority the impact of it running will be
> low, so we can set the interrupt status of the Thread. Thread.sleep
> and Object.wait methods will respond to the interrupted state, so
> eventually the thread will be interrupted and the smart proxy
> reference will be set to null, which causes all method calls to throw
> an IOException. The thread will eventually terminate, without taking
> out the JVM.
>
> Furthermore all objects created during unmarshalling are not shared,
> no blocking methods that ignore interruption will prevent the thread
> from being interrupted. If it's caught in an endless loop, the
> StackOverflowError will eventually be thrown and caught by the
> UncaughtExceptionHandler, which deletes the smart proxy reference and
> sets the correct state of the reflection proxy's InvocationHandler
> before it shuts down, causing all client calls to receive an IOException.
>
> MarshalledInstance contains the byte array for the objects already, so
> the thread won't block waiting on a Socket, ignoring the interrupt.
>
> Authentication doesn't utilise the proxy code, only local code, so if
> we can't authenticate, shut it down.
>
> I've got some sample code up on Pepe, have a look, time permitting,
> I'll expand it further, we can get some test cases going, if there's a
> show stopping issue we can't solve, then I'll drop the idea. So far I
> haven't discovered that show stopper.
>
> If you don't like the eventual solution, you can still vote against it
> before it gets merged, it may never get that far, you or I might
> discover that show stopper.
>
> Peter.
>
Sim,
Firstly let me say that I like your idea, a feature requiring a jar file
be signed by a known Certificate, before allowing class loading, I'd
like to implement it together, if your interested. This would provide
good security for parties already known to each other.
Back to the topic of the DOS attack, the ExecutorService Thread prevents
the client's thread memory stack from corruption / overflow.
It's worth noting the possibility that a clever attack implementation
thread may run a very long time. The attacker may use the static
Thread.interrupted method to reset the interrupted status of the thread,
so we'd be reliant on StackOverflowError to eventually stop it. There
are measures which can be taken to reduce the impact, such as setting
the thread priority very low, using the Java 5 Thread stack size
constructor, providing a minimal stack size, this would not be
consistent or guaranteed across all platforms, but would have to be
tested for each, the stack size would be equal or less than the other
running threads, depending on the minimum stack size allowable by the
platform. The stack size would also place a limit on the size of the
unmarshalled proxy.
An ideal attack implementation would be one that makes cpu intensive
calculations, but doesn't recurse the same methods too deeply, since the
number of times a method is recursed before a StackOverflowError is
thrown is limited by the stack size. Then the attacker would need many
service registrars to supply proxy's to unsuspecting clients, to produce
enough phantom threads to cause memory problems. The attack to be
successful needs many attack registrars, the goal; cause an
OutOfMemoryError, by creating too many threads. We could be talking
thousands of threads for this to work.
The important thing to remember is application performance would not
become degraded until memory is impacted.
The number of bad registrars would be the biggest issue.
We can discover registrars using DNS-SD, where each internet domain
specifies it's registrars (addresses and port numbers are discovered
using DNS-SD, so one firewall IP address can serve multiple registrars
spread over an arbitary range of ports).
(DNS-SD + Unicast Discovery = discovery of internet Registrar's) N.B.
I'm curious about RemoteEvent registrars, Michal?
The attacker would need to take advantage of a security vulnerability
provided by NAT Routers with UPnP to open firewall ports for computers
on private networks to create enough drone computers with bad registrars.
Are you familiar with the use of Canary's in Mining? Canary's were
taken underground by coal miners in the 19th Century, when gasses
reached dangerous levels, the more sensitive canary's, would be
affected, alerting miners and providing time for escape.
So what do we need for reliable services in the Face of DoS attacks? A
Canary, constantly searching all web domains for bad registrars, when it
discovers one it will notify a Server providing a Canary Service. When
the Canary is overrun by bad proxy threads, (all belong to a common
ThreadGroup and can be counted) it restarts it's JVM.
Each domain would provide it's own Canary Service along with it's own
Registrar's, clients in that domain would first discover a local
registrar, then lookup a Canary Service for a list of domains or
addresses of public registrar's to avoid. The known bad addresses would
then simply not be used in Unicast Discovery.
In effect your using known trusted Registrars to notify you of untrusted
ones you don't know.
The domain administrator might run a local domain canary looking for bad
proxy's from any services in their own domain, these bad services would
be removed from the registrar and their location tracked down.
Registrar Administrators in a domain might perform a search of canary
services in other domains to see if they have any bad local service
registrars operating from their network and shut them down too.
Most of this could be automated, so clients needn't be too concerned.
InternetServiceDiscoveryManager?
Registrars never unmarshall proxy's, they are immune in this regard to
the unmarshalling DoS attack.
A company may of course misuse the canary service by discouraging their
own domain clients from using particular domains.
This would work very similarly to signing Code and asking clients: "Do
you trust this code signer?" When you click ok and something bad
happens, you report it. With canary services, it could happen automagicly.
Clients discovering bad services in other domains could report these to
their local canary service.
The trick is to make the DoS attack ineffective enough that it can't
take down a client so easily, as it can now.
Right now, a client could be taken out simply with a never ending loop
from a single bad registrar. If instead we require two thousand bad
registrars to take out the client, we've raised the bar slightly higher.
Is it worth investigating further?
What say ye?
Cheers,
Peter.
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 10/06/2010 02:58 AM, Peter Firmstone wrote:
>>> I want this trust system to be dynamic. I want to be able to change my
>>> mind.
>>
>> Once you've loaded the class files, that's it, the ClassLoader will only
>> become garbage collected when no strong references to objects and class
>> files remain. You've only got one shot at that decision.
>
> Thats too much black and white for me. I was talking about multiple
> invocations of a VM. So that means remembering trust decisions.
That makes sense, perhaps you can share the trust decision and the
result of that decision by submitting it to a feedback service, your VM
could send this information before shutting down.
>
> I we have misbehaving code, we cannot stop it easily. So that means
> changing the trustlevel, and restarting the VM (no specific order).
Have you got any thoughts on trust levels?
> Or are you willing to use Thread.stop()?
>
>
No, first implement an UncaughtExceptionHandler, use it with a Single
threaded ExecutorService, also create a ThreadFactory that creates a
Thread utilising the UncaughtExceptionHandler.
This catches a StackOverflowError, we still need strategies for other
Errors. Instead of using Runnable, Callable is used so that the method
calls from the reflective proxy return any Exceptions, these can be
wrapped in an IOException for the client to handle.
Since the thread is a low priority the impact of it running will be low,
so we can set the interrupt status of the Thread. Thread.sleep and
Object.wait methods will respond to the interrupted state, so eventually
the thread will be interrupted and the smart proxy reference will be set
to null, which causes all method calls to throw an IOException. The
thread will eventually terminate, without taking out the JVM.
Furthermore all objects created during unmarshalling are not shared, no
blocking methods that ignore interruption will prevent the thread from
being interrupted. If it's caught in an endless loop, the
StackOverflowError will eventually be thrown and caught by the
UncaughtExceptionHandler, which deletes the smart proxy reference and
sets the correct state of the reflection proxy's InvocationHandler
before it shuts down, causing all client calls to receive an IOException.
MarshalledInstance contains the byte array for the objects already, so
the thread won't block waiting on a Socket, ignoring the interrupt.
Authentication doesn't utilise the proxy code, only local code, so if we
can't authenticate, shut it down.
I've got some sample code up on Pepe, have a look, time permitting, I'll
expand it further, we can get some test cases going, if there's a show
stopping issue we can't solve, then I'll drop the idea. So far I
haven't discovered that show stopper.
If you don't like the eventual solution, you can still vote against it
before it gets merged, it may never get that far, you or I might
discover that show stopper.
Peter.
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/06/2010 02:58 AM, Peter Firmstone wrote:
>> I want this trust system to be dynamic. I want to be able to change my
>> mind.
>
> Once you've loaded the class files, that's it, the ClassLoader will only
> become garbage collected when no strong references to objects and class
> files remain. You've only got one shot at that decision.
Thats too much black and white for me. I was talking about multiple
invocations of a VM. So that means remembering trust decisions.
I we have misbehaving code, we cannot stop it easily. So that means
changing the trustlevel, and restarting the VM (no specific order). Or
are you willing to use Thread.stop()?
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 10/05/2010 01:07 PM, Peter Firmstone wrote:
>> Yes I think Sim is talking about making trust decisions and Michal and I
>> are talking about the handshake, we need both, I don't think we're
>> having an issue of agreement, just understanding.
>
> No, i'm talking about both.
>
> Before you can unmarshall, you need code. This code is loaded by a
> classloader. The ONLY place where we can check code, is this classloader.
>
> For every trust decision i've made, the classloader should check if
> what is loaded is consistent with the trust decision i've made.
Aha you want to sign the jar and prevent class loading of unsigned
CodeSources.
>
> I want this trust system to be exclusive. Only when trust is granted
> am i willing to perform code i have been given.
Trust in our discussion's so far is based on the Subject of the
Services, ie Principals, I've had trouble with this too, Fred Oliver
helped me out. The difficulty with signing the jar file and using it
for the trust decision is, the CodeSource may be used by many, whom you
may have different trust relationships with.
The DOS issue we're dealing with is outside the Java security system, no
trust has yet been established or granted.
But yes, it would be possible to limit ClassLoading based on who has
signed the code.
>
> I want this trust system to be dynamic. I want to be able to change my
> mind.
Once you've loaded the class files, that's it, the ClassLoader will only
become garbage collected when no strong references to objects and class
files remain. You've only got one shot at that decision.
Currently the Java Security Model is also a one choice trust decision,
once you've granted trust, references to security sensitive objects
escape, the policy is no longer consulted, security sensitive object
references can leak into untrusted code, if we're not careful with our
programming. This is how you get a security exploit. Li Gongproposed
Security policy decision's being part of object implementation, rather
than something external to the object. To do this you create a suitable
guard in an objects constructor, this guard is checked on every
sensitive method invocation.
I'm working on trust revocation. I have a basic InternetSecurityManager,
two Security Delegates (FileInputStream and FileOutputStream) and
DelegatePermission's that represent another Permission but can be
revoked because Security Delegates use Li Gong's Object Method Guard
pattern. The InternetSecurityManager caches the results of permission
checks for each AccessControlContext, for rapid repeated checks.
>
> I want this trust system to be automated only in removing trust. I
> dont want to have a machine surprise me by downloading a trojan.
>
> I want this system to be certification friendly. So not only based on
> Principal alone.
If you have a look in my PermissionGrant implementation classes, I've
made it programatically possible to require that a ProtectionDomain have
Principal[]'s and it's CodeSource be signed by Certificate[]'s before
the grant is allowed.
So for ultimate security there might be a public clearing house for
review of code, compiled and signed by reputable developers after auditing.
A client might require Certificate[]'s as well as particular
Principal[]'s, this would provide a maximum security environment.
While that's good and highly recommended, it might be too much to impose
it on everyone.
I noticed that Maven provisioning and CodeSource caching has been
brought up again, these are ideas I support, we could use some
volunteers here, at the moment I'm on my own, I've had the
StreamServiceRegistrar interface up for a while (now in pepe under
org.apache.river.api.lookup) but haven't had any feedback.
At this stage I don't think we can envision eliminating dynamic code
downloads in favour of Maven Provisioning, since this is still in
gestation, We need a URL schema we can use for Maven provisioning so we
can obtain the maven URI from the proxy MarshalledInstance, and check we
have the correct archive with the provided checksum, or deliberately
specify another version.
Then we need an additional get() method that supplies our preferred
CodeSource to the MarshalledInstance for unmarshalling the proxy.
It's important to remember a Service may change it's proxy
implementation at any time, a client should never become dependent on a
particular implementation.
We certainly have made progress with understanding dependency
relationships between Service API, the service implementation, proxy and
client. If we make the ClassLoader inheritance hierarchy the same, then
all the ClassLoader issues go away.
For two Services with different Subjects and identical CodeSource, we
need two distinct separate ClassLoader instances,specifically for each
Subject, so static class variables can't be shared between them and the
trust decision for one Subject, doesn't apply to the other.
An applet get's it own ThreadGroup, ClassLoader and SecurityManager
which captures System.exit() and only terminates the applet rather than
the entire JVM. The applet is still unmarshalled even if unsigned, but
it is restricted to it's own thread group.
My intent was to restrict the proxy to a single Thread with a priority
of about 4, with it's own UncaughtExeceptionHandler. The proxy is
restricted to this thread during unmarshalling. Once the proxy has been
unmarshalled and trust has been verified based on authenticating the
Subject, the proxy can be safely executed on the client thread. While
the proxy is in quarantine, before trust is established, the client can
only call it via a reflection proxy that places all method calls on a
queue to be executed by the Quarantined Thread. Because the proxy is
not executing on the client thread, the client can't be taken down. The
proxy can only destroy itself.
If we do this, the attacker will have to instead attempt to fool the
authentication mechanism and then do something nasty.
If we use public key certificates for Subject's identity, then any
breaches of trust can be reported as bad feedback against these services
and the unstrustworthy service will find itself isolated.
To me, fixing the DOS attack is simpler for Application developers and
doesn't exclude adding the additional security benefits you're proposing
and we're not increasing the initial learning curve required of
application developers.
Regards,
Peter.
>
> Eh, would this constitute a requirements definition? :-)
>
> Gr. Sim
>
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/06/2010 01:38 AM, Dennis Reedy wrote:
> We had discussed this at great length (just about the length of this
> thread:)) back in May. Check out the "Codebase Service" thread for
> details.
:-) OK. But did we arrive at a River position on this. We should in the
end come up with some kind of 'best practices' documentation on the site.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Dennis Reedy <de...@gmail.com>.
On Oct 5, 2010, at 1000AM, Sim IJskes - QCG wrote:
> On 10/05/2010 03:48 PM, Dennis Reedy wrote:
>
>> Just curious here, what if the decision was that you can only load
>> classes locally? That in order to get your classes you had to first
>> download the jars from a (trusted) server (perhaps even prompting the
>> user to accept the download?). You would verify the authenticity of
>> those jars before creating a classloader to load the required
>> classes. If you already have the jars (locally) necessary, why
>> download them again?
>
> That would be my preferred way of security, matching practices already there. Signed jars, downloaded with webstart, and communicating over jini.
>
>> Consider you already have the service's interface (and any other
>> supporting classes) in your classpath to begin with (which is loaded
>> locally), why not provision the remote service's proxy jars first
>> before connecting to the service? Appropriate handshaking happens to
>> connect to the remote service of course, but do you take the dynamic
>> insecure class loading out of the equation this way?
>
> Yep.
>
> But i got the feeling that others within the river community still want to maintain the same 'code agility', as deployment on a lan.
I'm not sure that this approach impedes one bit on perceived 'code agility'. If anything it removes the troublesome issues that surround code servers, missing codebases and performance issues of constantly loading resources over the wire that (most likely) have been downloaded at some time in the past.
We had discussed this at great length (just about the length of this thread:)) back in May. Check out the "Codebase Service" thread for details.
Regards
Dennis
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/05/2010 03:48 PM, Dennis Reedy wrote:
> Just curious here, what if the decision was that you can only load
> classes locally? That in order to get your classes you had to first
> download the jars from a (trusted) server (perhaps even prompting the
> user to accept the download?). You would verify the authenticity of
> those jars before creating a classloader to load the required
> classes. If you already have the jars (locally) necessary, why
> download them again?
That would be my preferred way of security, matching practices already
there. Signed jars, downloaded with webstart, and communicating over jini.
> Consider you already have the service's interface (and any other
> supporting classes) in your classpath to begin with (which is loaded
> locally), why not provision the remote service's proxy jars first
> before connecting to the service? Appropriate handshaking happens to
> connect to the remote service of course, but do you take the dynamic
> insecure class loading out of the equation this way?
Yep.
But i got the feeling that others within the river community still want
to maintain the same 'code agility', as deployment on a lan.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Dennis Reedy <de...@gmail.com>.
On Oct 5, 2010, at 727AM, Sim IJskes - QCG wrote:
> On 10/05/2010 01:07 PM, Peter Firmstone wrote:
>> Yes I think Sim is talking about making trust decisions and Michal and I
>> are talking about the handshake, we need both, I don't think we're
>> having an issue of agreement, just understanding.
>
> No, i'm talking about both.
>
> Before you can unmarshall, you need code. This code is loaded by a classloader. The ONLY place where we can check code, is this classloader.
Just curious here, what if the decision was that you can only load classes locally? That in order to get your classes you had to first download the jars from a (trusted) server (perhaps even prompting the user to accept the download?). You would verify the authenticity of those jars before creating a classloader to load the required classes. If you already have the jars (locally) necessary, why download them again?
Consider you already have the service's interface (and any other supporting classes) in your classpath to begin with (which is loaded locally), why not provision the remote service's proxy jars first before connecting to the service? Appropriate handshaking happens to connect to the remote service of course, but do you take the dynamic insecure class loading out of the equation this way?
Dennis
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/05/2010 01:07 PM, Peter Firmstone wrote:
> Yes I think Sim is talking about making trust decisions and Michal and I
> are talking about the handshake, we need both, I don't think we're
> having an issue of agreement, just understanding.
No, i'm talking about both.
Before you can unmarshall, you need code. This code is loaded by a
classloader. The ONLY place where we can check code, is this classloader.
For every trust decision i've made, the classloader should check if what
is loaded is consistent with the trust decision i've made.
I want this trust system to be exclusive. Only when trust is granted am
i willing to perform code i have been given.
I want this trust system to be dynamic. I want to be able to change my mind.
I want this trust system to be automated only in removing trust. I dont
want to have a machine surprise me by downloading a trojan.
I want this system to be certification friendly. So not only based on
Principal alone.
Eh, would this constitute a requirements definition? :-)
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Yes I think Sim is talking about making trust decisions and Michal and I
are talking about the handshake, we need both, I don't think we're
having an issue of agreement, just understanding.
I'd like to see some kind of feedback service, where you give a good
rating when you get a good service and a bad one when you don't. I'd
also like to see a security advisory service, for handling discovered
vulnerabilities. These things might be useful in making trust decisions.
I'd also like some trust levels defined, with a wider range of
permissions as trust increases. But I'd only like to grant the
intersection of the trust level Set of Permissions and the Set requested.
I'd like to see the level of trust others are granting to a service via
feedback services, if a service misbehaves and it's caught out, the
level of trust will diminish.
Then we can go with the crowd, safety in numbers, like a school of fish,
just don't get caught in a bait ball.
Cheers,
Peter.
Michal Kleczek wrote:
> Of course - I am not talking about the problem of deciding whether I should
> trust a particular service - this is a completely different subject and I am
> not really sure if we should even try to solve it since I don't think it is
> possible to do without human intervention. In the end - choosing to trust and
> use gmail versus yahoo is not something that can be done automatically.
>
> But checking whether an object (code + data) comes from the service I trust is
> something that can be done and is a prerequisite to the above anyway.
>
> Michal
>
> On Tuesday 05 of October 2010 12:26:52 Michal Kleczek wrote:
>
>> Don't know if we agree or not :) . So to make it simple I'd say that the
>> way proxy verification is done in Jini is IMHO fine - except that it is
>> done too late (after deserialization which requires running yet untrusted
>> code). Once we have it fixed - we're basically ready for the Internet (
>> sure there other issues to solve but IMHO this is the most basic).
>>
>> Michal
>>
>> On Tuesday 05 of October 2010 12:11:18 Sim IJskes - QCG wrote:
>>
>>> On 10/04/2010 06:43 PM, Michal Kleczek wrote:
>>>
>>>> Let me explain my position better:
>>>>
>>>> IMHO the problem to solve is: how to securely exchange information
>>>> between two parties without trusting third parties that u use to
>>>> send/receive it?
>>>>
>>> By using cryptography.
>>>
>>>
>>>> Your example with JPEG is actually excellent to illustrate my point.
>>>> The only way to make sure you got your images from a trusted party is
>>>> to _always_ use TLS - no web caches/proxies or anything like that.
>>>> Once you have those - you're out in the dark.
>>>>
>>> Even when your HTTPS session goes through a proxy, it is still
>>> end-to-end. (unless you are victim of a MITM attack).
>>>
>>>
>>>> It is no different than exchanging objects using untrusted
>>>> ServiceRegistrars or code using untrusted code servers. It is actually
>>>> no different than downloading a web page from your bank site - the
>>>> bytes you actually download come from an untrusted router somewhere in
>>>> the net anyway.
>>>>
>>> But the mere fact that this router is untrusted does not reduce the
>>> level of security.
>>>
>>>
>>>> Also - relying on trusted third parties to download code gives you
>>>> false sense of security - users of Android or iPhone that download
>>>> apps from (trusted) app stores should already know that.
>>>>
>>> I'm not sure this creates a false sense of security. I've never thought
>>> is was secure. Did you? I much rather have my third party to be open
>>> about its practices than not.
>>>
>>>
>>>> The solution is not to reject using proxies or any third parties. It is
>>>> to 1. introduce a way for you to make sure the data you've just
>>>> downloaded comes from the right source - no matter what means you used
>>>> to download it. 2. restrict downloaded code as much as possible
>>>>
>>> The solution that is brewing does not reject proxies or third parties.
>>> It is more about accepting them, and remembering the trust choices we
>>> have made, and means to change this trust.
>>>
>>>
>>>> Jini is almost there - we have Java security to restrict downloaded
>>>> code and we have a way to verify if an object came from a trusted
>>>> source. The only problem is that to do that we have to run some yet
>>>> untrusted code. Let's just try to solve this problem :)
>>>>
>>> I'm still not sure if we agree or differ in opinion. Are you?
>>>
>>> Gr. Sim
>>>
>
>
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Of course - I am not talking about the problem of deciding whether I should
trust a particular service - this is a completely different subject and I am
not really sure if we should even try to solve it since I don't think it is
possible to do without human intervention. In the end - choosing to trust and
use gmail versus yahoo is not something that can be done automatically.
But checking whether an object (code + data) comes from the service I trust is
something that can be done and is a prerequisite to the above anyway.
Michal
On Tuesday 05 of October 2010 12:26:52 Michal Kleczek wrote:
> Don't know if we agree or not :) . So to make it simple I'd say that the
> way proxy verification is done in Jini is IMHO fine - except that it is
> done too late (after deserialization which requires running yet untrusted
> code). Once we have it fixed - we're basically ready for the Internet (
> sure there other issues to solve but IMHO this is the most basic).
>
> Michal
>
> On Tuesday 05 of October 2010 12:11:18 Sim IJskes - QCG wrote:
> > On 10/04/2010 06:43 PM, Michal Kleczek wrote:
> > > Let me explain my position better:
> > >
> > > IMHO the problem to solve is: how to securely exchange information
> > > between two parties without trusting third parties that u use to
> > > send/receive it?
> >
> > By using cryptography.
> >
> > > Your example with JPEG is actually excellent to illustrate my point.
> > > The only way to make sure you got your images from a trusted party is
> > > to _always_ use TLS - no web caches/proxies or anything like that.
> > > Once you have those - you're out in the dark.
> >
> > Even when your HTTPS session goes through a proxy, it is still
> > end-to-end. (unless you are victim of a MITM attack).
> >
> > > It is no different than exchanging objects using untrusted
> > > ServiceRegistrars or code using untrusted code servers. It is actually
> > > no different than downloading a web page from your bank site - the
> > > bytes you actually download come from an untrusted router somewhere in
> > > the net anyway.
> >
> > But the mere fact that this router is untrusted does not reduce the
> > level of security.
> >
> > > Also - relying on trusted third parties to download code gives you
> > > false sense of security - users of Android or iPhone that download
> > > apps from (trusted) app stores should already know that.
> >
> > I'm not sure this creates a false sense of security. I've never thought
> > is was secure. Did you? I much rather have my third party to be open
> > about its practices than not.
> >
> > > The solution is not to reject using proxies or any third parties. It is
> > > to 1. introduce a way for you to make sure the data you've just
> > > downloaded comes from the right source - no matter what means you used
> > > to download it. 2. restrict downloaded code as much as possible
> >
> > The solution that is brewing does not reject proxies or third parties.
> > It is more about accepting them, and remembering the trust choices we
> > have made, and means to change this trust.
> >
> > > Jini is almost there - we have Java security to restrict downloaded
> > > code and we have a way to verify if an object came from a trusted
> > > source. The only problem is that to do that we have to run some yet
> > > untrusted code. Let's just try to solve this problem :)
> >
> > I'm still not sure if we agree or differ in opinion. Are you?
> >
> > Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Don't know if we agree or not :) . So to make it simple I'd say that the way
proxy verification is done in Jini is IMHO fine - except that it is done too
late (after deserialization which requires running yet untrusted code). Once
we have it fixed - we're basically ready for the Internet ( sure there other
issues to solve but IMHO this is the most basic).
Michal
On Tuesday 05 of October 2010 12:11:18 Sim IJskes - QCG wrote:
> On 10/04/2010 06:43 PM, Michal Kleczek wrote:
> > Let me explain my position better:
> >
> > IMHO the problem to solve is: how to securely exchange information
> > between two parties without trusting third parties that u use to
> > send/receive it?
>
> By using cryptography.
>
> > Your example with JPEG is actually excellent to illustrate my point. The
> > only way to make sure you got your images from a trusted party is to
> > _always_ use TLS - no web caches/proxies or anything like that. Once you
> > have those - you're out in the dark.
>
> Even when your HTTPS session goes through a proxy, it is still
> end-to-end. (unless you are victim of a MITM attack).
>
> > It is no different than exchanging objects using untrusted
> > ServiceRegistrars or code using untrusted code servers. It is actually
> > no different than downloading a web page from your bank site - the bytes
> > you actually download come from an untrusted router somewhere in the net
> > anyway.
>
> But the mere fact that this router is untrusted does not reduce the
> level of security.
>
> > Also - relying on trusted third parties to download code gives you false
> > sense of security - users of Android or iPhone that download apps from
> > (trusted) app stores should already know that.
>
> I'm not sure this creates a false sense of security. I've never thought
> is was secure. Did you? I much rather have my third party to be open
> about its practices than not.
>
> > The solution is not to reject using proxies or any third parties. It is
> > to 1. introduce a way for you to make sure the data you've just
> > downloaded comes from the right source - no matter what means you used
> > to download it. 2. restrict downloaded code as much as possible
>
> The solution that is brewing does not reject proxies or third parties.
> It is more about accepting them, and remembering the trust choices we
> have made, and means to change this trust.
>
> > Jini is almost there - we have Java security to restrict downloaded code
> > and we have a way to verify if an object came from a trusted source. The
> > only problem is that to do that we have to run some yet untrusted code.
> > Let's just try to solve this problem :)
>
> I'm still not sure if we agree or differ in opinion. Are you?
>
> Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 10/4/2010 11:43 AM, Michal Kleczek wrote:
> Let me explain my position better:
>
> IMHO the problem to solve is: how to securely exchange information between two
> parties without trusting third parties that u use to send/receive it?
One of the interesting problems with mobile code, is how to trust what you
receive through a third party. Not that it is less valuable or entertaining to
hackers to corrupt any arbitrary stream of data between two parties.
> Your example with JPEG is actually excellent to illustrate my point. The only
> way to make sure you got your images from a trusted party is to _always_ use
> TLS - no web caches/proxies or anything like that. Once you have those -
> you're out in the dark.
> It is no different than exchanging objects using untrusted ServiceRegistrars or
> code using untrusted code servers. It is actually no different than downloading
> a web page from your bank site - the bytes you actually download come from an
> untrusted router somewhere in the net anyway.
>
Using TLS/SSL or some other signed (for validity of content) and encrypted (for
security of content) streaming protocol, for me, is the only choice we should
push out onto the internet.
> Also - relying on trusted third parties to download code gives you false sense
> of security - users of Android or iPhone that download apps from (trusted) app
> stores should already know that.
What the App Store does, it put value in "being kind", because people will pay
you to do something useful for them. What Apple's developers contract does, is
give them some remedy in the case that you "are not kind" so that they can
intervene for their customers.
There is nothing that can be guaranteed 100%. Apple, and their customers, have
accepted some level of "risk" for the benefits they perceive and receive from
the devices.
The Android "Marketplace" provides similar comforting provisions, but still has
no guarantees.
> The solution is not to reject using proxies or any third parties. It is to
> 1. introduce a way for you to make sure the data you've just downloaded comes
> from the right source - no matter what means you used to download it.
> 2. restrict downloaded code as much as possible
For 1), the problem is that you have to know ahead of time, what you've agreed
to, because httpmd: is based on you granting permissions to the codesource URL
based on your acceptance of its content as being valid. If the codesource URL
for something like httpmd: comes to you dynamically, how do you validate that it
has not been changed enroute?
> Jini is almost there - we have Java security to restrict downloaded code and
> we have a way to verify if an object came from a trusted source. The only
> problem is that to do that we have to run some yet untrusted code. Let's just
> try to solve this problem :)
> I've given a simple idea but I am still unsure if this is a solution or not :)
>
In a mostly static world, the unmarshall DOS attack is the thing that seems to
be the most visible hole left in the system. The layers in the other places you
mention provide some level of control, which seems adequately adjustable.
Gregg Wonderly
> Michal
>
> On Monday 04 of October 2010 14:38:01 Tom Hobbs wrote:
>> Isn't that the basic underpinning of secure web traffic?
>>
>> Maybe I'm being overly simplistic, but if I browse to www.mybank.com a
>> security handshake happens and then anything that server sends me, be it
>> images, JavaScript, data etc, sends me I implicitly trust. If I log into
>> gmail.com or amazon.com or whatever, additional handshakes with those
>> (code)servers happens again.
>>
>> If I get a service proxy from apache.org, then I can implicitly trust it.
>> If I download a service proxy from dodgyproxies.com, a site I've never
>> heard of before, then I shouldn't be suprised if it trashed my machine.
>>
>> How is downloading and running a service proxy any different from
>> downloading and opening/viewing/running anything else? I think that's the
>> basic concept I'm struggling with. Think back to the bug in JPEG which
>> allowed malicious code to execute when infected images were viewed (I
>> forget the exact details), but the point of the matter is; if you only got
>> images from places you trusted, you didn't have to disassemble each image
>> file to check it for malicious code. If you downloaded images from other
>> places, then, well, it was generally accepted as your fault.
>>
>> To me, downloading and running a proxy doesn't seem to be any different
>> from downloading an executable script or program from the web and clicking
>> on my browsers "Run" button rather than the "Save" button.
>>
>> Sim's idea of trusting certain places not to intentionally serve you Bad
>> Stuff, appears to me to be a mirror of what already happens anyway.
>>
>> What am I missing?
>>
>> Maybe the question is just "But where are these trusted places I can get
>> service proxies from?" To which the answer is, "No where yet, we haven't
>> decided if that really is the best thing to do." :-)
>>
>> Cheers,
>>
>> Tom
>>
>> On Mon, Oct 4, 2010 at 1:25 PM, Michal Kleczek
> <mi...@xpro.biz>wrote:
>>> On Monday 04 of October 2010 14:09:06 Sim IJskes - QCG wrote:
>>>> On 10/04/2010 01:54 PM, Michal Kleczek wrote:
>>>>>> This is why TLS is so important. With TLS you have authentication
>>>>>> and encryption in one solution. You can configure the level of
>>>>>> encryption and the mechnisms for authentication differently for
>>>>>> each application.
>>>>>>
>>>>>> It provides you with an end-to-end solution, so you can use any
>>> insecure
>>>
>>>>>> path you like.
>>>>> So you meant TLS between the client and the service in your previous
>>>>> post? But how can the client communicate with the service before
>>>>> unmarshalling the service proxy?
>>>> Before i can start unmarshalling, i need to load the class from the
>>>> classloader. This classloader connects to the code providing server.
>>>> The classloader and server handshake, and exchange certificates. If
>>>> anything is fishy, the connection is severed, and whe only have lost
>>>> the few bytes from the handshake.
>>> Sure - I understand that.
>>> My point is actually that it requires trust relationship with the code
>>> server.
>>> In other words - for me to securely communicate with you we both have to
>>> trust
>>> a single third party (the code server). I don't want that - I just trust
>>> you
>>> but neither you nor I have the necessary infrastructure to have a trusted
>>> code
>>> server - can we still securely communicate using GMail as our code
>>> server?.
>>>
>>> Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/04/2010 06:43 PM, Michal Kleczek wrote:
> Let me explain my position better:
>
> IMHO the problem to solve is: how to securely exchange information between two
> parties without trusting third parties that u use to send/receive it?
By using cryptography.
> Your example with JPEG is actually excellent to illustrate my point. The only
> way to make sure you got your images from a trusted party is to _always_ use
> TLS - no web caches/proxies or anything like that. Once you have those -
> you're out in the dark.
Even when your HTTPS session goes through a proxy, it is still
end-to-end. (unless you are victim of a MITM attack).
> It is no different than exchanging objects using untrusted ServiceRegistrars or
> code using untrusted code servers. It is actually no different than downloading
> a web page from your bank site - the bytes you actually download come from an
> untrusted router somewhere in the net anyway.
But the mere fact that this router is untrusted does not reduce the
level of security.
> Also - relying on trusted third parties to download code gives you false sense
> of security - users of Android or iPhone that download apps from (trusted) app
> stores should already know that.
I'm not sure this creates a false sense of security. I've never thought
is was secure. Did you? I much rather have my third party to be open
about its practices than not.
> The solution is not to reject using proxies or any third parties. It is to
> 1. introduce a way for you to make sure the data you've just downloaded comes
> from the right source - no matter what means you used to download it.
> 2. restrict downloaded code as much as possible
The solution that is brewing does not reject proxies or third parties.
It is more about accepting them, and remembering the trust choices we
have made, and means to change this trust.
> Jini is almost there - we have Java security to restrict downloaded code and
> we have a way to verify if an object came from a trusted source. The only
> problem is that to do that we have to run some yet untrusted code. Let's just
> try to solve this problem :)
I'm still not sure if we agree or differ in opinion. Are you?
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Let me explain my position better:
IMHO the problem to solve is: how to securely exchange information between two
parties without trusting third parties that u use to send/receive it?
Your example with JPEG is actually excellent to illustrate my point. The only
way to make sure you got your images from a trusted party is to _always_ use
TLS - no web caches/proxies or anything like that. Once you have those -
you're out in the dark.
It is no different than exchanging objects using untrusted ServiceRegistrars or
code using untrusted code servers. It is actually no different than downloading
a web page from your bank site - the bytes you actually download come from an
untrusted router somewhere in the net anyway.
Also - relying on trusted third parties to download code gives you false sense
of security - users of Android or iPhone that download apps from (trusted) app
stores should already know that.
The solution is not to reject using proxies or any third parties. It is to
1. introduce a way for you to make sure the data you've just downloaded comes
from the right source - no matter what means you used to download it.
2. restrict downloaded code as much as possible
Jini is almost there - we have Java security to restrict downloaded code and
we have a way to verify if an object came from a trusted source. The only
problem is that to do that we have to run some yet untrusted code. Let's just
try to solve this problem :)
I've given a simple idea but I am still unsure if this is a solution or not :)
Michal
On Monday 04 of October 2010 14:38:01 Tom Hobbs wrote:
> Isn't that the basic underpinning of secure web traffic?
>
> Maybe I'm being overly simplistic, but if I browse to www.mybank.com a
> security handshake happens and then anything that server sends me, be it
> images, JavaScript, data etc, sends me I implicitly trust. If I log into
> gmail.com or amazon.com or whatever, additional handshakes with those
> (code)servers happens again.
>
> If I get a service proxy from apache.org, then I can implicitly trust it.
> If I download a service proxy from dodgyproxies.com, a site I've never
> heard of before, then I shouldn't be suprised if it trashed my machine.
>
> How is downloading and running a service proxy any different from
> downloading and opening/viewing/running anything else? I think that's the
> basic concept I'm struggling with. Think back to the bug in JPEG which
> allowed malicious code to execute when infected images were viewed (I
> forget the exact details), but the point of the matter is; if you only got
> images from places you trusted, you didn't have to disassemble each image
> file to check it for malicious code. If you downloaded images from other
> places, then, well, it was generally accepted as your fault.
>
> To me, downloading and running a proxy doesn't seem to be any different
> from downloading an executable script or program from the web and clicking
> on my browsers "Run" button rather than the "Save" button.
>
> Sim's idea of trusting certain places not to intentionally serve you Bad
> Stuff, appears to me to be a mirror of what already happens anyway.
>
> What am I missing?
>
> Maybe the question is just "But where are these trusted places I can get
> service proxies from?" To which the answer is, "No where yet, we haven't
> decided if that really is the best thing to do." :-)
>
> Cheers,
>
> Tom
>
> On Mon, Oct 4, 2010 at 1:25 PM, Michal Kleczek
<mi...@xpro.biz>wrote:
> > On Monday 04 of October 2010 14:09:06 Sim IJskes - QCG wrote:
> > > On 10/04/2010 01:54 PM, Michal Kleczek wrote:
> > > >> This is why TLS is so important. With TLS you have authentication
> > > >> and encryption in one solution. You can configure the level of
> > > >> encryption and the mechnisms for authentication differently for
> > > >> each application.
> > > >>
> > > >> It provides you with an end-to-end solution, so you can use any
> >
> > insecure
> >
> > > >> path you like.
> > > >
> > > > So you meant TLS between the client and the service in your previous
> > > > post? But how can the client communicate with the service before
> > > > unmarshalling the service proxy?
> > >
> > > Before i can start unmarshalling, i need to load the class from the
> > > classloader. This classloader connects to the code providing server.
> > > The classloader and server handshake, and exchange certificates. If
> > > anything is fishy, the connection is severed, and whe only have lost
> > > the few bytes from the handshake.
> >
> > Sure - I understand that.
> > My point is actually that it requires trust relationship with the code
> > server.
> > In other words - for me to securely communicate with you we both have to
> > trust
> > a single third party (the code server). I don't want that - I just trust
> > you
> > but neither you nor I have the necessary infrastructure to have a trusted
> > code
> > server - can we still securely communicate using GMail as our code
> > server?.
> >
> > Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/04/2010 02:25 PM, Michal Kleczek wrote:
> Sure - I understand that.
> My point is actually that it requires trust relationship with the code server.
> In other words - for me to securely communicate with you we both have to trust
> a single third party (the code server). I don't want that - I just trust you
> but neither you nor I have the necessary infrastructure to have a trusted code
> server - can we still securely communicate using GMail as our code server?.
Yes we can. But not for the part of downloading the code from gmail.
I guess you are refering to the case where the code is provided by
another place than where the ServerEndpoint is located. And the code
providers tls session does not have access to the private key that was
used for signing the code. I haven't thought about that one (yet). But i
guess that one is also solvable.
My original thinking was about a code server service, running on the
same ServerEndpoint as the service.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Monday 04 of October 2010 15:39:44 Sim IJskes - QCG wrote:
> On 10/04/2010 03:28 PM, Michal Kleczek wrote:
> > The service can upload it's code to any code server available (it does
> > not have to be trusted). It can upload it's proxy to any untrusted
> > ServiceRegistrar or JavaSpace available.
> > Yet still - the client can make sure it is talking to the right service
> > via the right proxy.
> > The only hole is that a DOS attack during proxy deserialization can be
> > issued by a malicious service registrar. The question is - can this
> > problem be solved?
>
> I'm not sure, thats the only attack vector. The problem is already
> present in the lower layer: JERI.
>
> To me a service registrar is nothing more than a lookup table,
> associating service attributes with service UUID, and service UUID with
> ServerEndpoint+Object UUID. When you have selected the service, your
> classloader still has to download the code, but thats the responsibility
> of classloader and codeserver, who are verifying the trust relation.
It does not matter how the client got the proxy (be it from a
ServiceRegistrar, an email message or a JavaSpace).
You use a Security.verifyObjectTrust() to check if the proxy is the right one.
This in turn establishes a secure channel with the service (which _must_
authenticate to the client in a secure setup) to retrieve a verifier.
The problem is - you have to first deserialize the proxy. During
deserialization or downloaded class initialization and then when retrieving
ProxyTrustIterator the only thing that can happen ( if JVM security does not
have holes ) is DoS since the code does not yet have any permissions.
Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/04/2010 03:28 PM, Michal Kleczek wrote:
> The service can upload it's code to any code server available (it does not
> have to be trusted). It can upload it's proxy to any untrusted
> ServiceRegistrar or JavaSpace available.
> Yet still - the client can make sure it is talking to the right service via
> the right proxy.
> The only hole is that a DOS attack during proxy deserialization can be issued
> by a malicious service registrar. The question is - can this problem be
> solved?
I'm not sure, thats the only attack vector. The problem is already
present in the lower layer: JERI.
To me a service registrar is nothing more than a lookup table,
associating service attributes with service UUID, and service UUID with
ServerEndpoint+Object UUID. When you have selected the service, your
classloader still has to download the code, but thats the responsibility
of classloader and codeserver, who are verifying the trust relation.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Monday 04 of October 2010 14:57:48 Sim IJskes - QCG wrote:
> On 10/04/2010 02:38 PM, Tom Hobbs wrote:
> > Isn't that the basic underpinning of secure web traffic?
> >
> > Maybe I'm being overly simplistic, but if I browse to www.mybank.com a
> > security handshake happens and then anything that server sends me, be it
> > images, JavaScript, data etc, sends me I implicitly trust. If I log into
> > gmail.com or amazon.com or whatever, additional handshakes with those
> > (code)servers happens again.
> >
> > If I get a service proxy from apache.org, then I can implicitly trust it.
> >
> > If I download a service proxy from dodgyproxies.com, a site I've never
> >
> > heard of before, then I shouldn't be suprised if it trashed my machine.
>
> Exactly. And if you want to download anything from another place than
> the original source, you have to trust the 'codeproxy' and add it to
> your trustlist (for downloading). You still have to verify the code
> against the trustlist for its certificate+codehash. It waters down the
> guarantees a bit, but only for the part of the spent bytes from your
> dataroaming plan. And maybe it would be wise to put that roque codeproxy
> on your 'i will never trust them again' list.
Of course - you can always say - just use trusted intermediaries.
But IMHO it is a step back from where Jini _already_ is.
The service can upload it's code to any code server available (it does not
have to be trusted). It can upload it's proxy to any untrusted
ServiceRegistrar or JavaSpace available.
Yet still - the client can make sure it is talking to the right service via
the right proxy.
The only hole is that a DOS attack during proxy deserialization can be issued
by a malicious service registrar. The question is - can this problem be
solved?
If you connect to https://www.mybank.com - you actually use several third
parties to communicate with your bank - you don't trust them but you're sure
communication is secure.
Why would a code server or a ServiceRegistrar have to be trusted while the
routers between you and the bank don't have to?
When you download log4j.jar from doggyjars.com - is it possible to make sure
it is really log4j.jar? Of course it is - you just check if checksum matches
with the one you know is from a trusted source.
So if it is possible - why do we have to restrict ourselves to trusted
websites for downloading code? Or trusted ServiceRegistrars for downloading
proxies?
Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/04/2010 02:38 PM, Tom Hobbs wrote:
> Isn't that the basic underpinning of secure web traffic?
>
> Maybe I'm being overly simplistic, but if I browse to www.mybank.com a
> security handshake happens and then anything that server sends me, be it
> images, JavaScript, data etc, sends me I implicitly trust. If I log into
> gmail.com or amazon.com or whatever, additional handshakes with those
> (code)servers happens again.
>
> If I get a service proxy from apache.org, then I can implicitly trust it.
> If I download a service proxy from dodgyproxies.com, a site I've never
> heard of before, then I shouldn't be suprised if it trashed my machine.
Exactly. And if you want to download anything from another place than
the original source, you have to trust the 'codeproxy' and add it to
your trustlist (for downloading). You still have to verify the code
against the trustlist for its certificate+codehash. It waters down the
guarantees a bit, but only for the part of the spent bytes from your
dataroaming plan. And maybe it would be wise to put that roque codeproxy
on your 'i will never trust them again' list.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Tom Hobbs <tv...@googlemail.com>.
Isn't that the basic underpinning of secure web traffic?
Maybe I'm being overly simplistic, but if I browse to www.mybank.com a
security handshake happens and then anything that server sends me, be it
images, JavaScript, data etc, sends me I implicitly trust. If I log into
gmail.com or amazon.com or whatever, additional handshakes with those
(code)servers happens again.
If I get a service proxy from apache.org, then I can implicitly trust it.
If I download a service proxy from dodgyproxies.com, a site I've never
heard of before, then I shouldn't be suprised if it trashed my machine.
How is downloading and running a service proxy any different from
downloading and opening/viewing/running anything else? I think that's the
basic concept I'm struggling with. Think back to the bug in JPEG which
allowed malicious code to execute when infected images were viewed (I forget
the exact details), but the point of the matter is; if you only got images
from places you trusted, you didn't have to disassemble each image file to
check it for malicious code. If you downloaded images from other places,
then, well, it was generally accepted as your fault.
To me, downloading and running a proxy doesn't seem to be any different from
downloading an executable script or program from the web and clicking on my
browsers "Run" button rather than the "Save" button.
Sim's idea of trusting certain places not to intentionally serve you Bad
Stuff, appears to me to be a mirror of what already happens anyway.
What am I missing?
Maybe the question is just "But where are these trusted places I can get
service proxies from?" To which the answer is, "No where yet, we haven't
decided if that really is the best thing to do." :-)
Cheers,
Tom
On Mon, Oct 4, 2010 at 1:25 PM, Michal Kleczek <mi...@xpro.biz>wrote:
> On Monday 04 of October 2010 14:09:06 Sim IJskes - QCG wrote:
> > On 10/04/2010 01:54 PM, Michal Kleczek wrote:
> > >> This is why TLS is so important. With TLS you have authentication and
> > >> encryption in one solution. You can configure the level of encryption
> > >> and the mechnisms for authentication differently for each application.
> > >>
> > >> It provides you with an end-to-end solution, so you can use any
> insecure
> > >> path you like.
> > >
> > > So you meant TLS between the client and the service in your previous
> > > post? But how can the client communicate with the service before
> > > unmarshalling the service proxy?
> >
> > Before i can start unmarshalling, i need to load the class from the
> > classloader. This classloader connects to the code providing server. The
> > classloader and server handshake, and exchange certificates. If anything
> > is fishy, the connection is severed, and whe only have lost the few
> > bytes from the handshake.
>
> Sure - I understand that.
> My point is actually that it requires trust relationship with the code
> server.
> In other words - for me to securely communicate with you we both have to
> trust
> a single third party (the code server). I don't want that - I just trust
> you
> but neither you nor I have the necessary infrastructure to have a trusted
> code
> server - can we still securely communicate using GMail as our code server?.
>
> Michal
>
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Monday 04 of October 2010 14:09:06 Sim IJskes - QCG wrote:
> On 10/04/2010 01:54 PM, Michal Kleczek wrote:
> >> This is why TLS is so important. With TLS you have authentication and
> >> encryption in one solution. You can configure the level of encryption
> >> and the mechnisms for authentication differently for each application.
> >>
> >> It provides you with an end-to-end solution, so you can use any insecure
> >> path you like.
> >
> > So you meant TLS between the client and the service in your previous
> > post? But how can the client communicate with the service before
> > unmarshalling the service proxy?
>
> Before i can start unmarshalling, i need to load the class from the
> classloader. This classloader connects to the code providing server. The
> classloader and server handshake, and exchange certificates. If anything
> is fishy, the connection is severed, and whe only have lost the few
> bytes from the handshake.
Sure - I understand that.
My point is actually that it requires trust relationship with the code server.
In other words - for me to securely communicate with you we both have to trust
a single third party (the code server). I don't want that - I just trust you
but neither you nor I have the necessary infrastructure to have a trusted code
server - can we still securely communicate using GMail as our code server?.
Michal
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Sorry for double emails - my email client got confused...
Please do not respond to this...
Michal
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mk...@contour-technology.com>.
On Monday 04 of October 2010 14:09:06 Sim IJskes - QCG wrote:
> On 10/04/2010 01:54 PM, Michal Kleczek wrote:
> >> This is why TLS is so important. With TLS you have authentication and
> >> encryption in one solution. You can configure the level of encryption
> >> and the mechnisms for authentication differently for each application.
> >>
> >> It provides you with an end-to-end solution, so you can use any insecure
> >> path you like.
> >
> > So you meant TLS between the client and the service in your previous
> > post? But how can the client communicate with the service before
> > unmarshalling the service proxy?
>
> Before i can start unmarshalling, i need to load the class from the
> classloader. This classloader connects to the code providing server. The
> classloader and server handshake, and exchange certificates. If anything
> is fishy, the connection is severed, and whe only have lost the few
> bytes from the handshake.
Sure - I understand that.
My point is actually that it requires trust relationship with the code server.
In other words - for me to securely communicate with you we both have to trust
a single third party (the code server). I don't want that - I just trust you
but neither you nor I have the necessary infrastructure to have a trusted code
server - can we still securely communicate using GMail as our code server?.
Michal
Re: Towards Internet Jini Services (trust)
Posted by Tom Hobbs <tv...@googlemail.com>.
I like this. Sim is formalising something that I've been failing to
articulate properly.
Programmatically protecting a JVM from a malicious proxy is a Hard Thing to
do, which doesn't mean we shouldn't do it. But this approach seems cleaner
in many ways. Not to mention it's based on existing security patterns.
On Mon, Oct 4, 2010 at 1:09 PM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 10/04/2010 01:54 PM, Michal Kleczek wrote:
>
>> This is why TLS is so important. With TLS you have authentication and
>>> encryption in one solution. You can configure the level of encryption
>>> and the mechnisms for authentication differently for each application.
>>>
>>> It provides you with an end-to-end solution, so you can use any insecure
>>> path you like.
>>>
>>
>> So you meant TLS between the client and the service in your previous post?
>> But how can the client communicate with the service before unmarshalling
>> the
>> service proxy?
>>
>
> Before i can start unmarshalling, i need to load the class from the
> classloader. This classloader connects to the code providing server. The
> classloader and server handshake, and exchange certificates. If anything is
> fishy, the connection is severed, and whe only have lost the few bytes from
> the handshake.
>
> Gr. Sim
>
>
>
>
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/04/2010 01:54 PM, Michal Kleczek wrote:
>> This is why TLS is so important. With TLS you have authentication and
>> encryption in one solution. You can configure the level of encryption
>> and the mechnisms for authentication differently for each application.
>>
>> It provides you with an end-to-end solution, so you can use any insecure
>> path you like.
>
> So you meant TLS between the client and the service in your previous post?
> But how can the client communicate with the service before unmarshalling the
> service proxy?
Before i can start unmarshalling, i need to load the class from the
classloader. This classloader connects to the code providing server. The
classloader and server handshake, and exchange certificates. If anything
is fishy, the connection is severed, and whe only have lost the few
bytes from the handshake.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mk...@contour-technology.com>.
On Monday 04 of October 2010 13:51:12 Sim IJskes - QCG wrote:
> On 10/04/2010 01:42 PM, Michal Kleczek wrote:
> > I don't think it is impossible since I do it all the time -
> > switches/bridges/routers are third parties that I do not trust but I use
> > them to securely communicate with my bank :) Why code servers or
> > ServiceRegistrars should be any different?
>
> This is why TLS is so important. With TLS you have authentication and
> encryption in one solution. You can configure the level of encryption
> and the mechnisms for authentication differently for each application.
>
> It provides you with an end-to-end solution, so you can use any insecure
> path you like.
So you meant TLS between the client and the service in your previous post?
But how can the client communicate with the service before unmarshalling the
service proxy?
Michal
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 10/04/2010 05:49 PM, Mike McGrady wrote:
>> I think that we need to decide what the requirements are? Anyone
>> else thinking this? NSA has a tee shirt saying, "We trust in trust".
>
> Defining requirements is good. But an excercise determining if jini is
> ready for the internet is also good. This excercise can consist of
> discussion of pros and cons of keeping the existing code, or adding
> code to it. By having arguments and counter arguments we can build an
> (collective) instinctive feeling for the strength and weaknesses of jini.
>
> I'm sure the original jini team had similar discussions, maybe not
> over email, but more around a beer, or at the coffee machine. We need
> to rebuild this team coherence.
>
> Gr. Sim
>
> BTW: i also do trust trust, and even i trust trust is trust.
>
Ok, my thoughts, the team that produced the Jini security infrastructure
were a smart bunch, we can utilise any provider we like, it's very
pluggable, fortunate are we. We're also very fortunate for the
brilliant security foundation in the JVM, Li didn't get to go all the
way like he wanted, but his team managed to make history.
The whole escaped reference security auditing problem in Java wouldn't
exist if Li's Guard Pattern was utilised for methods in all Java's
security sensitive classes.
If you read the Jini Davis project interviews on Artima between Bill
Venners and Bob Scheiffler, you soon realise that they knew Jini
Security wasn't quite finished.
I'm not saying don't change the code, or that it's perfect (anything
that's perfect is obsolete since it no longer changes, sorry can't
remember the author), I'm saying, hmm there are some issues, lets
investigate them.
Jini's model of trust is quite clever, it's a key component,
establishment of trust has been implemented, we have SSL and Kerberos
JERI Endpoint Client's for Unicast discovery, so the Registrar proxy
objects (in serialized form) coming down the wire are private, between
the client and the registrar. We have integrity, Jini verify's that the
CodeSource has the correct checksum, specified by the remote Registrar.
The catch, there's this short period, where we haven't authenticated the
Registrar, or verified the proxy, to do that we must ask the proxy for
it's bootstrap proxy (a piece of local code) required for
authentication. To authenticate, we must unmarshall the proxy.
When we unmarshall the proxy, we're exposed to a DOS attack, no loss of
private information, no real security hazard, just the irritation that
Jini Service based Software will be made up of both Services and Clients
and the DOS attack makes it brittle.
So I agree, trust is important.
To build team coherence, we must be prepared to listen and learn from
the old hands who volunteer information, building cases for arguments
just makes them fall silent. When someone puts forward an opposing
view, you don't have to take sides, it's better to just ask questions.
The reason that Jini wasn't a howling success like Java was not the
fault of the code, I just think the timing wasn't right, it wasn't
finished and has some areas we need to work on, we have people like
Peter Jones, Tim Blackman, Dennis Reedy, Gregg Wonderly, Michel Kleczek,
Chris Dolan, Zoltan Juhasz, Fred Oliver, Greg Trasuk, even Jim Waldo
occasionally, Jim Hurley and Brian Murphy, who know the issues and are
prepared to share their knowledge. (Sorry if I've forgotten anyone -
off the top of my head, no particular order) but we've also got our team
of regular committers, Jonathan, Patricia, Sim, Tom and myself.
It's important we examine the code, ask questions respectfully and learn
from each other. It is difficult working from opposite sides of the
world, we've got cultural differences, there's no body language to
assist, but I'm confident we can work it out.
Cheers,
Peter.
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/04/2010 05:49 PM, Mike McGrady wrote:
> I think that we need to decide what the requirements are? Anyone else thinking this? NSA has a tee shirt saying, "We trust in trust".
Defining requirements is good. But an excercise determining if jini is
ready for the internet is also good. This excercise can consist of
discussion of pros and cons of keeping the existing code, or adding code
to it. By having arguments and counter arguments we can build an
(collective) instinctive feeling for the strength and weaknesses of jini.
I'm sure the original jini team had similar discussions, maybe not over
email, but more around a beer, or at the coffee machine. We need to
rebuild this team coherence.
Gr. Sim
BTW: i also do trust trust, and even i trust trust is trust.
Re: Towards Internet Jini Services (trust)
Posted by Mike McGrady <mm...@topiatechnology.com>.
I think that we need to decide what the requirements are? Anyone else thinking this? NSA has a tee shirt saying, "We trust in trust".
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Oct 4, 2010, at 5:04 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 10/04/2010 01:42 PM, Michal Kleczek wrote:
>>> A possible solution might be, to enforce code download to use TLS and
>>> verify if the othersides ceritificate matches the downloaders trustlist.
>>> We can extends this by enforcing the downloaded jars/classes to be
>>> signed with a similar certificate.
>>>
>>> A "once bitten measure" could be, if a server violates this rule, it
>>> will automatically be taken of the trustlist.
>>
>> I am not sure how it would bring me closer to "The Ultimate Goal" which is to
>> make it possible for two parties to securely communicate without relying on
>> third parties being trusted or even related with the two parties in any way
>> regarding trust - but still allow _using_ those untrusted third parties to
>> exchange information.
>
> You don't need to trust a third party. If i have got your certificate in my trustlist, and i trust you to do the right thing, i can download your code and execute it whenever i want it. And i can continue doing this, as long as i trust you or your organisation.
>
> I can also delegate this trust to the 'apache foundation jini code clearing house' for instance and trust that if you abuse this trust, someone from the crowd will inform the clearing house, and they revoke their trust.
>
> The only thing that we need, for environments where certification is important, that we allow for specific baselines to be trusted by a clearinghouse (for example the cerification organisation). So that if a malicious party provides an update, with malicious code inserted, the new certificate+codehash does not match an existing entry in my trustlist.
>
> Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/04/2010 01:42 PM, Michal Kleczek wrote:
>> A possible solution might be, to enforce code download to use TLS and
>> verify if the othersides ceritificate matches the downloaders trustlist.
>> We can extends this by enforcing the downloaded jars/classes to be
>> signed with a similar certificate.
>>
>> A "once bitten measure" could be, if a server violates this rule, it
>> will automatically be taken of the trustlist.
>
> I am not sure how it would bring me closer to "The Ultimate Goal" which is to
> make it possible for two parties to securely communicate without relying on
> third parties being trusted or even related with the two parties in any way
> regarding trust - but still allow _using_ those untrusted third parties to
> exchange information.
You don't need to trust a third party. If i have got your certificate in
my trustlist, and i trust you to do the right thing, i can download your
code and execute it whenever i want it. And i can continue doing this,
as long as i trust you or your organisation.
I can also delegate this trust to the 'apache foundation jini code
clearing house' for instance and trust that if you abuse this trust,
someone from the crowd will inform the clearing house, and they revoke
their trust.
The only thing that we need, for environments where certification is
important, that we allow for specific baselines to be trusted by a
clearinghouse (for example the cerification organisation). So that if a
malicious party provides an update, with malicious code inserted, the
new certificate+codehash does not match an existing entry in my trustlist.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/04/2010 01:42 PM, Michal Kleczek wrote:
> I don't think it is impossible since I do it all the time -
> switches/bridges/routers are third parties that I do not trust but I use them
> to securely communicate with my bank :) Why code servers or ServiceRegistrars
> should be any different?
This is why TLS is so important. With TLS you have authentication and
encryption in one solution. You can configure the level of encryption
and the mechnisms for authentication differently for each application.
It provides you with an end-to-end solution, so you can use any insecure
path you like.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
On Monday 04 of October 2010 12:37:15 Sim IJskes - QCG wrote:
> On 10/01/2010 03:00 PM, Michal Kleczek wrote:
> > 3. I agree with Tom that making sure the code comes from a known source
> > is enough to make a decision whether to run this code or not. But Jini
> > already checks that (well... almost)- the only hole is that the check is
> > done _after_ deserialization - so it means the code was executed
> > _before_ the check was done. My question actually is - why don't we
> > check an object before it is deserialized?
>
> A possible solution might be, to enforce code download to use TLS and
> verify if the othersides ceritificate matches the downloaders trustlist.
> We can extends this by enforcing the downloaded jars/classes to be
> signed with a similar certificate.
>
> A "once bitten measure" could be, if a server violates this rule, it
> will automatically be taken of the trustlist.
I am not sure how it would bring me closer to "The Ultimate Goal" which is to
make it possible for two parties to securely communicate without relying on
third parties being trusted or even related with the two parties in any way
regarding trust - but still allow _using_ those untrusted third parties to
exchange information.
I don't think it is impossible since I do it all the time -
switches/bridges/routers are third parties that I do not trust but I use them
to securely communicate with my bank :) Why code servers or ServiceRegistrars
should be any different?
We're almost there:
- we have httpmd to stop relying on code servers being trusted
- we have TrustVerifier to stop relying on third parties such as
ServiceRegistrars or JavaSpaces or EventMailboxes being trusted.
The only ( good question actually :) ) hole is deserialization - a malicious
ServiceRegistrar or JavaSpace can try a DOS attack before the two parties can
establish trust.
We can always use RequireDlPermProvider and restrict CodeSources from which we
allow defining classes. But:
a) it either requires using known code servers (which in turn makes it
impossible to download code using for example some P2P infrastructure)
b) code signing is expensive - at least the one requiring x509 certificates (we
do not have PGP or SPKI code signing in Java)
Michal
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/01/2010 03:00 PM, Michal Kleczek wrote:
> 3. I agree with Tom that making sure the code comes from a known source is
> enough to make a decision whether to run this code or not. But Jini already
> checks that (well... almost)- the only hole is that the check is done _after_
> deserialization - so it means the code was executed _before_ the check was
> done. My question actually is - why don't we check an object before it is
> deserialized?
A possible solution might be, to enforce code download to use TLS and
verify if the othersides ceritificate matches the downloaders trustlist.
We can extends this by enforcing the downloaded jars/classes to be
signed with a similar certificate.
A "once bitten measure" could be, if a server violates this rule, it
will automatically be taken of the trustlist.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michal Kleczek <mi...@xpro.biz>.
Folks,
I'm reading this thread with a lot of interest and wanted to throw my 2 cents.
1. I think we should stop talking about "services" and "service registrars"
when talking about downloading code - RemoteEventListener can be a smart proxy
too...
2. Java permissioning model is enough to trust that code will not do anything
bad like read my bank account credentials. Of course we cannot check that the
code does not have any bugs - we cannot solve halting problem anyway...
3. I agree with Tom that making sure the code comes from a known source is
enough to make a decision whether to run this code or not. But Jini already
checks that (well... almost)- the only hole is that the check is done _after_
deserialization - so it means the code was executed _before_ the check was
done. My question actually is - why don't we check an object before it is
deserialized?
My idea would be as follows:
a) _Never_ download code when deserializing data (objects) comming from the
network (IOW MarshalledInputStream should behave like ObjectInputStream - use
TCCL to load classes)
b) when sending a proxy wrap it in a dynamic proxy with invocation handler
that has two objects: a ProxyTrust and a marshalled real proxy
c) upon receiving of a (smart) proxy prepare it using a preparer that wraps
original proxy with the one that makes sure TCCL is set apropriatelly for each
method invocation - this is necessary so that deserialization of subsequent
objects received by the proxy is successful (see point a).
The preparer would check if it is preparing the proxy with
TrustedInvocationHandler, then verifiy trust using std. Jini trust verification,
then retrieve the real proxy, get it's ClassLoader and return a TCCL setting
proxy wrapping it..
Some code:
//returned by remote service
//cannot deserialize passed instance before actually making the check
//it is not a problem for the client because it is obtained from a trusted
//ProxyTrust implementation
interface MarshalledInstanceVerifier {
boolean isTrustedMarshalledInstance(MarshalledInstance<?> instance);
}
class TrustedInvocationHandler implements InvocationHandler {
private MarshalledInstance<?> realProxy;
private ProxyTrust proxyTrust;
Object getRealProxy() {
return realProxy.get();
}
ClassLoader getRealProxyClassLoader() {
return getRealProxy().getClassLoader();
}
protected ProxyTrustIterator getProxyTrustIterator() {
return new SingletonProxyTrustIterator(proxyTrust);
}
}
class TrustedInvocationHandlerVerifier implements TrustVerifier {
private MarshalledInstanceVerifier delegate;
public boolean isTrustedObject(Object o, TrustVerifier.Context ctx) {
//check that o is a proxy with TrustedInvocationHandler
//...
TrustedInvocationHandler handler = ...
return delegate.isTrustedMarshalledInstance(handler.realProxy);
}
}
What do you think?
Michal
On Friday 01 of October 2010 14:05:51 Zoltan Juhasz wrote:
> Tom and all,
>
> > When was the last time you analysed the contents of your
> > newly downloaded log4j.jar, just to make sure it didn't
> > contain anything nasty? In that example, you trusted the
> > download site (apache.org), and you trusted the download
> > mechanism (HTTP - now that was risky!), and then you trusted
> > the stuff you downloaded.
>
> I think this is a key observation. The Jini mechanism for trust is based on
> trusting the source and the download channel but that does not imply
> anything about the quality of the code you're about to execute. When you
> download anything manually (in your browser), you have time to decide
> whether or not you take the risk. Jini however is about programmatic
> clients doing this automatically without human intervention. The speed of
> execution is at a different scale. One would need semantic correctness
> checks which is impossible to do right now. We had bumped into this
> problem when we used Jini for distributed/parallel computation and the
> only solution we could come up was to have accountability and a mechanism
> for non-repudiation, ie you code can do stupid things but I'll catch you
> and make you pay for it.
>
> I don't know whether there is a universal solution to this, it is a very
> complicated problem.
>
> Zoltan
Re: lunch!
Posted by Tom Hobbs <tv...@googlemail.com>.
Wow, it's alright for some!
We ran out of bread so no sandwiches for me today. I'll be enjoying a
(second) bowl of muesli.
On Fri, Oct 1, 2010 at 12:57 PM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 10/01/2010 01:51 PM, Tom Hobbs wrote:
>
>> 3) Who else thinks it's time for lunch?
>>
>
> Be my guest. Just ate the leftovers from the Indonesian rijsttafel from
> last night!
>
> http://www.google.com/images?q=rijsttafel
>
> Gr. Sim
>
lunch!
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/01/2010 01:51 PM, Tom Hobbs wrote:
> 3) Who else thinks it's time for lunch?
Be my guest. Just ate the leftovers from the Indonesian rijsttafel from
last night!
http://www.google.com/images?q=rijsttafel
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Tom Hobbs <tv...@googlemail.com>.
> you have time to decide whether or not you take the risk.
You're right, you do. But I'm not convinced that this makes much of a
difference.
In your browser, if you click on a nasty link and suddenly start seeing
horrible pictures appear on your screen, sure you can go back, cancel or
stop your browser. Realistically, you've only got while the page is
downloading in which to change your mind. (Even less now that some browsers
will start rendering/running that page before the download is complete.)
But chances are, that nasty Java Script at the top of the page has already
done something malicious before you had a chance to stop it.
In your service browser, you can click on the download button of some Jini
service to download the proxy for it, and you've only got the amount of time
it takes to do the download to change your mind (assuming there is no "Proxy
downloaded, are you sure you want to use?" type dialog).
There is a much greater time lag between downloading a malicious JAR file
and running it. I absolutely agree with you; but once you've downloaded
what's the probability that you're going to inspect the code before deciding
whether or not to run it?
> trusting the source ... does not imply anything about the quality of the
code you're about to execute
I disagree, and I use the example of Log4J (again) to demonstrate this. I
trust Apache, tons of other people do to. I trust that the code I download
is both well intentioned and correctly written. I can honestly say that I
have never verified either assumption, nor restricted my Log4J usage
environment to prevent it from doing anything "bad".
I can completely believe that trust and security is very difficult, that
you're far better at it than me and have forgotten more about it than I'll
ever know. What I'm suggesting though, is to shift the goal posts so we
only have to solve a (hopefully) more simple problem.
If you trust my (public) ServiceRegistrar and you trust the download
channel, can you be convinced to trust whatever proxy you request from me?
If we can make that answer "yes", then all the proxy permission difficulty
suddenly goes away.
On Fri, Oct 1, 2010 at 1:05 PM, Zoltan Juhasz <ju...@irt.vein.hu> wrote:
> Tom and all,
>
> > When was the last time you analysed the contents of your
> > newly downloaded log4j.jar, just to make sure it didn't
> > contain anything nasty? In that example, you trusted the
> > download site (apache.org), and you trusted the download
> > mechanism (HTTP - now that was risky!), and then you trusted
> > the stuff you downloaded.
>
> I think this is a key observation. The Jini mechanism for trust is based on
> trusting the source and the download channel but that does not imply
> anything about the quality of the code you're about to execute. When you
> download anything manually (in your browser), you have time to decide
> whether or not you take the risk. Jini however is about programmatic
> clients
> doing this automatically without human intervention. The speed of execution
> is at a different scale. One would need semantic correctness checks which
> is
> impossible to do right now. We had bumped into this problem when we used
> Jini for distributed/parallel computation and the only solution we could
> come up was to have accountability and a mechanism for non-repudiation, ie
> you code can do stupid things but I'll catch you and make you pay for it.
>
> I don't know whether there is a universal solution to this, it is a very
> complicated problem.
>
> Zoltan
>
>
>
RE: Towards Internet Jini Services (trust)
Posted by Zoltan Juhasz <ju...@irt.vein.hu>.
Tom and all,
> When was the last time you analysed the contents of your
> newly downloaded log4j.jar, just to make sure it didn't
> contain anything nasty? In that example, you trusted the
> download site (apache.org), and you trusted the download
> mechanism (HTTP - now that was risky!), and then you trusted
> the stuff you downloaded.
I think this is a key observation. The Jini mechanism for trust is based on
trusting the source and the download channel but that does not imply
anything about the quality of the code you're about to execute. When you
download anything manually (in your browser), you have time to decide
whether or not you take the risk. Jini however is about programmatic clients
doing this automatically without human intervention. The speed of execution
is at a different scale. One would need semantic correctness checks which is
impossible to do right now. We had bumped into this problem when we used
Jini for distributed/parallel computation and the only solution we could
come up was to have accountability and a mechanism for non-repudiation, ie
you code can do stupid things but I'll catch you and make you pay for it.
I don't know whether there is a universal solution to this, it is a very
complicated problem.
Zoltan
Re: Towards Internet Jini Services (trust)
Posted by Tom Hobbs <tv...@googlemail.com>.
When we talk about "users" what do we mean? Who is the target?
It sounds like trusting the service proxy that got downloaded is a Hard
Problem to solve, is there any mileage is shifting things so we can instead
solve a different problem?
Developers use stuff they download from Apache because of the reputation, or
they'll use an Amazon or Google services because they know and trust the
names. Securing Internet-wide ServiceRegistrars to only be *joined* by
other trusted sources, and allowing easy download and use of those proxies
is probably an easier security problem to deal with. As long as we trust
that those SRs only have nice things on them, and that we can trust the
download channel (SSL or similar). Then a lot of the "should I trust this
proxy" issues just go away because the answer is implicitly 'yes'.
When was the last time you analysed the contents of your newly downloaded
log4j.jar, just to make sure it didn't contain anything nasty? In that
example, you trusted the download site (apache.org), and you trusted the
download mechanism (HTTP - now that was risky!), and then you trusted the
stuff you downloaded.
If you download log4j.jar from somewhere else, then trust becomes an issue
and there is nothing to protect you from it. Other than the rapid sequence
of "downloaded bad proxy --> computer explodes" compared to "downloaded
dodgy JAR --> computer explodes", what are the differences between this
example and downloading some service proxy?
The same can be said from the average Joe Bloggs browsing for fun-looking
services. He he downloads and runs something from somewhere he trusts (like
a certain app store) then he'll be okay he can trust the code he downloads
without having to restrict or protect himself against. If he gets a service
from some other dodgy site, then, well, I hope he has a backup!
You're never going to stop someone/anyone from downloading anything from
anywhere and running it. If you make something idiot-proof, the universe
will just come up with a better idiot.
So my questions are:
1) Does this approach lack something compared to the "Can my client trust
this proxy which I just downloaded?" approach?
2) Is enforcing security in the join mechanism easier?
3) Who else thinks it's time for lunch?
Cheers,
Tom
On Fri, Oct 1, 2010 at 12:21 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> I think we have to be very careful about placing the burden of security
> decisions on users, history has shown the user makes bad choices.
>
> Perhaps what we could come up with are some questions to help determine
> trust.
>
> The user might be able to obtain some feedback from other's who have used
> the service.
>
> Then based on the feedback the user provides about the level of trust, we
> can determine if the Permission's the service has requested is consistent
> with the level of trust.
>
> We have to be careful of information loss and privacy first and foremost.
>
> Note that Google abandoned the Java fine grained permission model in
> Android. That aside, this research paper using tainted variables in Android
> holds some valuable lessons.
>
>
> http://yro.slashdot.org/story/10/09/30/1640223/Many-More-Android-Apps-Leaking-User-Data
>
> I think corporate environments are generally slow adopters of technology.
>
> Cheer,
>
> Peter.
>
>
> 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.
>>
>> 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
>>
>>
>
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/01/2010 01:21 PM, Peter Firmstone wrote:
> I think we have to be very careful about placing the burden of security
> decisions on users, history has shown the user makes bad choices.
I'm a strong believer in trustchains. Because this is how humans already
work, 'your friend is my friend', and technology should support the
already existing mechanisms, not deteriorate it.
> Then based on the feedback the user provides about the level of trust,
> we can determine if the Permission's the service has requested is
> consistent with the level of trust.
A sort of 'crowd clearing' vs 'clearinghouse'?
> I think corporate environments are generally slow adopters of technology.
But i think we can solve the problems of both communities (corporate &
private).
Signing with a certificate and allowing only specific signatures, will
allow for rigid certification safeguards.
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
I think we have to be very careful about placing the burden of security
decisions on users, history has shown the user makes bad choices.
Perhaps what we could come up with are some questions to help determine
trust.
The user might be able to obtain some feedback from other's who have
used the service.
Then based on the feedback the user provides about the level of trust,
we can determine if the Permission's the service has requested is
consistent with the level of trust.
We have to be careful of information loss and privacy first and foremost.
Note that Google abandoned the Java fine grained permission model in
Android. That aside, this research paper using tainted variables in
Android holds some valuable lessons.
http://yro.slashdot.org/story/10/09/30/1640223/Many-More-Android-Apps-Leaking-User-Data
I think corporate environments are generally slow adopters of technology.
Cheer,
Peter.
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.
>
> 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
>
Re: Towards Internet Jini Services (trust)
Posted by Mike McGrady <mm...@topiatechnology.com>.
LOL
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Oct 4, 2010, at 2:45 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 10/01/2010 08:02 PM, Michael McGrady wrote:
>> Might be helpful - a little nightstand reading.
>>
>> http://www.csl.sri.com/~neumann/chats4.pdf
>
> Thanks. However, it did not fit my little nightstand! Are you sure you used a little one? :-)
>
> Gr. Sim
>
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/01/2010 08:02 PM, Michael McGrady wrote:
> Might be helpful - a little nightstand reading.
>
> http://www.csl.sri.com/~neumann/chats4.pdf
Thanks. However, it did not fit my little nightstand! Are you sure you
used a little one? :-)
Gr. Sim
Re: Towards Internet Jini Services (trust)
Posted by Michael McGrady <mm...@topiatechnology.com>.
Might be helpful - a little nightstand reading.
http://www.csl.sri.com/~neumann/chats4.pdf
On Oct 1, 2010, at 8:52 AM, 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
>>
>
Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
mmcgrady@topiatechnology.com
IMPORTANT NOTICE: This transmission is intended to be delivered only to the named recipient(s) and may contain material that is confidential, proprietary or subject to legal or other protection or privilege. If you are not the intended recipient(s) (or authorized to receive for the recipient), please contact the sender by reply email immediately and delete all copies of this transmission from your systems. Review, dissemination or disclosure, further transmission or other use of, or action taken in reliance on information contained in this transmission by anyone other than the intended recipient(s) is not authorized.
Re: Towards Internet Jini Services (trust)
Posted by Peter Firmstone <ji...@zeus.net.au>.
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
>>
>
>
Re: Towards Internet Jini Services (trust) Service UI
Posted by Peter Firmstone <ji...@zeus.net.au>.
Z Juhasz wrote:
> Greg,
>
>> 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.
>>
>
> Exactly. Different trust evalutation is essential in the ServiceUI case. We
> have had these problems many times. This is a very different mode of
> operation from that of the original Jini programmatic clients only view.
>
> Zoltan
>
>
>
Can you tell me more about some of the problems you've experienced,
trying to determine trust using Service UI? Perhaps we can figure
something out?
Service UI is much more flexible than a Jini Service by itself, since
the ServiceUI is really only tied to a JFrame rather than the Service
API which has to be known in advance.
When you think about Service UI, a single UI instance will work on many
services with identical Service API, it really depends on the client
Java platform, as to the Service UI instance chosen. A company will
want to provide their own look and feel. I guess different Service UI
could be akin to skins in media players.
But Service UI also enables the use of anonymous Service API, that is
not known in advance or may not be publicly available.
Any ideas?
Peter.
RE: Towards Internet Jini Services (trust)
Posted by Z Juhasz <z6...@gmail.com>.
Greg,
>
> 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.
Exactly. Different trust evalutation is essential in the ServiceUI case. We
have had these problems many times. This is a very different mode of
operation from that of the original Jini programmatic clients only view.
Zoltan
Re: Towards Internet Jini Services (trust)
Posted by Gregg Wonderly <gr...@wonderly.org>.
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
>
Re: Towards Internet Jini Services (trust)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
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.
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
Re: Towards Internet Jini Services (why)
Posted by Peter Firmstone <ji...@zeus.net.au>.
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
>>>
>>>
>>
>>
>
>
Re: Towards Internet Jini Services (why)
Posted by Gregg Wonderly <gr...@wonderly.org>.
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'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.
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.
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.
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
>>
>>
>
>
Re: Towards Internet Jini Services (why)
Posted by Peter Firmstone <ji...@zeus.net.au>.
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
>
>