Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
Oh I thought it was part of your SmartProxyWrapper? Who'd have thought you were talking about my work lol! I wouldn't agree with me either! My work: 1. new secure discovery protocols that include registrar codebase url and signers. 2. authenticate lookup service during disco, grant minimal permissions if auth successful. If unsuccessful no codebase download no deserialization. 3. lookup service proxy can't unmarshall proxy's from other services (insufficient permission), only has auth for its smart proxy url. 4. lookup service can only return dynamic proxy tokens that the proxy preparer can use to contact and authenticate each service. These tokens are loaded in lookup service proxy ClassLoader (sorry no codebase annotations, no codebase downloads, min permission). Lookup service not granted permission to make network connections, can't unmarshall smart proxys for other services. 5. All communications over trusted connections after auth. 6. Input validation for deserialization. The code and docs are on github for all to see. The interfaces the tokens impliment are documented in SafeServiceRegistrar. The code actually does what I've described above, but don't take my word for it, check it for youself. :) If you disagree, don't use it. There is no highlander principle here, you are free to implement alternatives. In fact I encourage you to do so as this can only serve to increase understanding. Cheers, Peter Sent from my Samsung device. Include original message Original message From: Michał Kłeczek Sent: 15/02/2017 05:00:14 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy They are valid questions and you haven't answered any of them. I've described _your_ way of thinking (which I do not agree with). Apache River has many problems both technical and organizational But I find the idea interesting and was expecting openness for contributions and open discussion. This is an open source project and there are no obligations to take part in the discussion nor answer any questions. But I find your patronizing statement disincentive to contribute to this project - especially that you are one of its main contributors. Regards, Michal Peter wrote: > Finding the answer to this question should assist you to discover answers to >many of the other questions you've had. > > While I've done my best to answer as many of your questions as I can, time is >limited and I haven't had time to answer all of them or rebutt or confirm all >arguments / assumptions. Sometimes the right questions are more important >than answers. > > Regards, > > Peter. > > Sent from my Samsung device. > >Include original message > Original message > From: Peter > Sent: 15/02/2017 12:58:55 pm > To: dev@river.apache.org > Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation >strategy > > The PreferredClassLoader will attempt to download the jar file in order to >get the preferred list. > > DownloadPermission should be called DefineClassPermission, I don't think it >will prevent download of the jar per say. > > Why must the bootstrap proxy be loaded by the codebase ClassLoader? > > Regards, > > Peter. > > Sent from my Samsung device. > >Include original message > Original message > From: Michał Kłeczek > Sent: 15/02/2017 06:20:37 am > To: dev@river.apache.org > Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation >strategy > > So I've given it some thought and the only explanation I can come up > with is: > > 1. To create an instance of the bootstrap proxy you need the codebase > annotation. > 2. Codebase annotation is needed because you want the bootstrap proxy's > class to be > defined in the proper codebase ClassLoader > 3. Since you do not want to allow any code downloads before placing > constraints on the > bootstrap proxy - it has to be a dynamic proxy. That way its class can > be defined by the codebase loader > and yet no code is downloaded > > So the overall sequence is as follows: > 1. Get the codebase annotation and create the codebase loader > 2. Create an instance of a dynamic proxy of a class defined by the > codebase loader > 3. IMPORTANT - before creating the proxy instance DO NOT grant any > download permissions > - that way we are sure the proxy does not triggers any code download and > execution due > to it implementing some foreign interfaces > 4. Once the proxy is instantiated - grant its ClassLoader download > permissions > 5. Place the constraints on the proxy > 6. Invoke a remote method on the proxy > > I understand the whole thing is to make sure the bootstrap proxy > is defined by the codebase ClassLoader - and the ClassLoader is needed > to be able to > dynamically grant download permissions. > > What I DO NOT
Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
N.B. Clarification on item 4. This is for cases when we really want to lock down the registrar. Once the token has been confirmed as trusted and an instance of java.lang.reflect.Proxy, it can be marshalled and unmarshalled into the Client's ClassLoader, the client uses it to authenicate the service download the smart proxy etc. As all the tokens have identical classes with the same interfaces, only one dynamic proxy class is generated in each ClassLoader where it is used. This is the proxy preparers responsibility. Regards, Peter. Sent from my Samsung device. Include original message Original message From: Peter Sent: 15/02/2017 07:01:06 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy Oh I thought it was part of your SmartProxyWrapper? Who'd have thought you were talking about my work lol! I wouldn't agree with me either! My work: 1. new secure discovery protocols that include registrar codebase url and signers. 2. authenticate lookup service during disco, grant minimal permissions if auth successful. If unsuccessful no codebase download no deserialization. 3. lookup service proxy can't unmarshall proxy's from other services (insufficient permission), only has auth for its smart proxy url. 4. lookup service can only return dynamic proxy tokens that the proxy preparer can use to contact and authenticate each service. These tokens are loaded in lookup service proxy ClassLoader (sorry no codebase annotations, no codebase downloads, min permission). Lookup service not granted permission to make network connections, can't unmarshall smart proxys for other services. 5. All communications over trusted connections after auth 6. Input validation for deserialization. The code and docs are on github for all to see. The interfaces the tokens impliment are documented in SafeServiceRegistrar. The code actually does what I've described above, but don't take my word for it, check it for youself. :) If you disagree, don't use it. There is no highlander principle here, you are free to implement alternatives. In fact I encourage you to do so as this can only serve to increase understanding. Cheers, Peter Sent from my Samsung device. Include original message Original message From: Michał Kłeczek Sent: 15/02/2017 05:00:14 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy They are valid questions and you haven't answered any of them. I've described _your_ way of thinking (which I do not agree with). Apache River has many problems both technical and organizational But I find the idea interesting and was expecting openness for contributions and open discussion. This is an open source project and there are no obligations to take part in the discussion nor answer any questions. But I find your patronizing statement disincentive to contribute to this project - especially that you are one of its main contributors. Regards, Michal Peter wrote: > Finding the answer to this question should assist you to discover answers to >many of the other questions you've had. > > While I've done my best to answer as many of your questions as I can, time is >limited and I haven't had time to answer all of them or rebutt or confirm all >arguments / assumptions. Sometimes the right questions are more important >than answers. > > Regards, > > Peter. > > Sent from my Samsung device. > >Include original message > Original message > From: Peter > Sent: 15/02/2017 12:58:55 pm > To: dev@river.apache.org > Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation >strategy > > The PreferredClassLoader will attempt to download the jar file in order to >get the preferred list. > > DownloadPermission should be called DefineClassPermission, I don't think it >will prevent download of the jar per say. > > Why must the bootstrap proxy be loaded by the codebase ClassLoader? > > Regards, > > Peter. > > Sent from my Samsung device. > >Include original message > Original message > From: Michał Kłeczek > Sent: 15/02/2017 06:20:37 am > To: dev@river.apache.org > Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation >strategy > > So I've given it some thought and the only explanation I can come up > with is: > > 1. To create an instance of the bootstrap proxy you need the codebase > annotation. > 2. Codebase annotation is needed because you want the bootstrap proxy's > class to be > defined in the proper codebase ClassLoader > 3. Since you do not want to allow any code downloads before placing > constraints on the > bootstrap proxy - it has to be a dynamic proxy. That way its class can > be defined by the codebase loader > and yet no code is downloaded > > So the overall sequence is as follows: > 1. Get the
Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
Miscommunication... as usual :D Anyway - I was really interested why you find the need for the bootstrap proxy to be necesarilly a dynamic proxy (since you seemed to find it very important from the security standpoint) - wanted to find out whether there were any issues in my thinking about providing a "code downloading object". Seems like there are not. Cheers, Michal Peter wrote: Oh I thought it was part of your SmartProxyWrapper? Who'd have thought you were talking about my work lol! I wouldn't agree with me either! My work: 1. new secure discovery protocols that include registrar codebase url and signers. 2. authenticate lookup service during disco, grant minimal permissions if auth successful. If unsuccessful no codebase download no deserialization. 3. lookup service proxy can't unmarshall proxy's from other services (insufficient permission), only has auth for its smart proxy url. 4. lookup service can only return dynamic proxy tokens that the proxy preparer can use to contact and authenticate each service. These tokens are loaded in lookup service proxy ClassLoader (sorry no codebase annotations, no codebase downloads, min permission). Lookup service not granted permission to make network connections, can't unmarshall smart proxys for other services. 5. All communications over trusted connections after auth. 6. Input validation for deserialization. The code and docs are on github for all to see. The interfaces the tokens impliment are documented in SafeServiceRegistrar. The code actually does what I've described above, but don't take my word for it, check it for youself. :) If you disagree, don't use it. There is no highlander principle here, you are free to implement alternatives. In fact I encourage you to do so as this can only serve to increase understanding. Cheers, Peter Sent from my Samsung device. Include original message Original message From: Michał Kłeczek Sent: 15/02/2017 05:00:14 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy They are valid questions and you haven't answered any of them. I've described _your_ way of thinking (which I do not agree with). Apache River has many problems both technical and organizational But I find the idea interesting and was expecting openness for contributions and open discussion. This is an open source project and there are no obligations to take part in the discussion nor answer any questions. But I find your patronizing statement disincentive to contribute to this project - especially that you are one of its main contributors. Regards, Michal Peter wrote: Finding the answer to this question should assist you to discover answers to many of the other questions you've had. While I've done my best to answer as many of your questions as I can, time is limited and I haven't had time to answer all of them or rebutt or confirm all arguments / assumptions. Sometimes the right questions are more important than answers. Regards, Peter. Sent from my Samsung device. Include original message Original message From: Peter Sent: 15/02/2017 12:58:55 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy The PreferredClassLoader will attempt to download the jar file in order to get the preferred list. DownloadPermission should be called DefineClassPermission, I don't think it will prevent download of the jar per say. Why must the bootstrap proxy be loaded by the codebase ClassLoader? Regards, Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek Sent: 15/02/2017 06:20:37 am To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy So I've given it some thought and the only explanation I can come up with is: 1. To create an instance of the bootstrap proxy you need the codebase annotation. 2. Codebase annotation is needed because you want the bootstrap proxy's class to be defined in the proper codebase ClassLoader 3. Since you do not want to allow any code downloads before placing constraints on the bootstrap proxy - it has to be a dynamic proxy. That way its class can be defined by the codebase loader and yet no code is downloaded So the overall sequence is as follows: 1. Get the codebase annotation and create the codebase loader 2. Create an instance of a dynamic proxy of a class defined by the codebase loader 3. IMPORTANT - before creating the proxy instance DO NOT grant any download permissions - that way we are sure the proxy does not triggers any code download and execution due to it implementing some foreign interfaces 4. Once the proxy is instantiated - grant its ClassLoader download permissions 5. Place t
Re: deserialization remote invocation strategy
The code actually does what I've described above, but don't take my word for it, check it for youself. :) If you disagree, don't use it. It works the other way around - before I decide to use it - I have to understand how it works. Even more so if we are talking about security. That is why I consider scrutiny and questioning a Good Thing in this context. "Check for yourself" is not an encouraging advice in the area of security :) Cheers, Michal
Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
A code downloading object is of course possible. If you implement it, I can review it from a security perspective if you like. Cheers, Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek Sent: 15/02/2017 07:48:48 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy Miscommunication... as usual :D Anyway - I was really interested why you find the need for the bootstrap proxy to be necesarilly a dynamic proxy (since you seemed to find it very important from the security standpoint) - wanted to find out whether there were any issues in my thinking about providing a "code downloading object". Seems like there are not. Cheers, Michal Peter wrote: > Oh I thought it was part of your SmartProxyWrapper? > > Who'd have thought you were talking about my work lol! I wouldn't agree with >me either! > > My work: > 1. new secure discovery protocols that include registrar codebase url and >signers. > 2. authenticate lookup service during disco, grant minimal permissions if >auth successful. If unsuccessful no codebase download no deserialization. > 3. lookup service proxy can't unmarshall proxy's from other services >(insufficient permission), only has auth for its smart proxy url. > 4. lookup service can only return dynamic proxy tokens that the proxy >preparer can use to contact and authenticate each service. These tokens are >loaded in lookup service proxy ClassLoader (sorry no codebase annotations, no >codebase downloads, min permission). Lookup service not granted permission to >make network connections, can't unmarshall smart proxys for other services. > 5. All communications over trusted connections after auth. > 6. Input validation for deserialization. > > The code and docs are on github for all to see. The interfaces the tokens >impliment are documented in SafeServiceRegistrar. > > The code actually does what I've described above, but don't take my word for >it, check it for youself. :) > > If you disagree, don't use it. There is no highlander principle here, you >are free to implement alternatives. In fact I encourage you to do so as this >can only serve to increase understanding. > > Cheers, > > Peter > > > > Sent from my Samsung device. > >Include original message > Original message > From: Michał Kłeczek > Sent: 15/02/2017 05:00:14 pm > To: dev@river.apache.org > Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation >strategy > > They are valid questions and you haven't answered any of them. > I've described _your_ way of thinking (which I do not agree with). > > Apache River has many problems both technical and organizational > But I find the idea interesting and was expecting openness > for contributions and open discussion. > > This is an open source project and there are no obligations to take part > in the discussion nor answer any questions. > But I find your patronizing statement disincentive to contribute to this > project - especially that you are one of its main contributors. > > Regards, > Michal > > Peter wrote: >> Finding the answer to this question should assist you to discover answers >>to many of the other questions you've had. >> >> While I've done my best to answer as many of your questions as I can, time >>is limited and I haven't had time to answer all of them or rebutt or confirm >>all arguments / assumptions. Sometimes the right questions are more >>important than answers. >> >> Regards, >> >> Peter. >> >> Sent from my Samsung device. >> >> Include original message >> Original message >> From: Peter >> Sent: 15/02/2017 12:58:55 pm >> To: dev@river.apache.org >> Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote >>invocation strategy >> >> The PreferredClassLoader will attempt to download the jar file in order to >>get the preferred list. >> >> DownloadPermission should be called DefineClassPermission, I don't think >>it will prevent download of the jar per say. >> >> Why must the bootstrap proxy be loaded by the codebase ClassLoader? >> >> Regards, >> >> Peter. >> >> Sent from my Samsung device. >> >> Include original message >> Original message >> From: Michał Kłeczek >> Sent: 15/02/2017 06:20:37 am >> To: dev@river.apache.org >> Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote >>invocation strategy >> >> So I've given it some thought and the only explanation I can come up >> with is: >> >> 1. To create an instance of the bootstrap proxy you need the codebase >> annotation. >> 2. Codebase annotation is needed because you want the bootstrap proxy's >> class to be >> defined in the proper codebase ClassLoader >> 3. Since you do not want to allow any co
Re: deserialization remote invocation strategy
I can't make any guarantee that it is secure, but the more people review it, the more likelihood bugs and flaws will be identified. I'm especially interested in security researchers checking it out if they're interested. Cheers, Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek Sent: 15/02/2017 08:04:39 pm To: dev@river.apache.org Subject: Re: deserialization remote invocation strategy > The code actually does what I've described above, but don't take my word for >it, check it for youself. :) > > If you disagree, don't use it. It works the other way around - before I decide to use it - I have to understand how it works. Even more so if we are talking about security. That is why I consider scrutiny and questioning a Good Thing in this context. "Check for yourself" is not an encouraging advice in the area of security :) Cheers, Michal
Re: deserialization remote invocation strategy
Reviewing just the source code without any high level overview and explanation how and why it is implemented in a particular way is difficult (if possible at all). That is why it would be really helpful if the questions asked were answered. Not only researchers are interested - also potential users and contributors. Thanks, Michal Peter wrote: I can't make any guarantee that it is secure, but the more people review it, the more likelihood bugs and flaws will be identified. I'm especially interested in security researchers checking it out if they're interested. Cheers, Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek Sent: 15/02/2017 08:04:39 pm To: dev@river.apache.org Subject: Re: deserialization remote invocation strategy The code actually does what I've described above, but don't take my word for it, check it for youself. :) If you disagree, don't use it. It works the other way around - before I decide to use it - I have to understand how it works. Even more so if we are talking about security. That is why I consider scrutiny and questioning a Good Thing in this context. "Check for yourself" is not an encouraging advice in the area of security :) Cheers, Michal
Re: deserialization remote invocation strategy
I still have some contacts into the UCSD computer science department from when I was doing my PhD. If we had a stated security model, it might be worth asking whether any students are interested in reviewing it. On 2/15/2017 3:07 AM, Michał Kłeczek wrote: Reviewing just the source code without any high level overview and explanation how and why it is implemented in a particular way is difficult (if possible at all). That is why it would be really helpful if the questions asked were answered. Not only researchers are interested - also potential users and contributors. Thanks, Michal Peter wrote: I can't make any guarantee that it is secure, but the more people review it, the more likelihood bugs and flaws will be identified. I'm especially interested in security researchers checking it out if they're interested. Cheers, Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek Sent: 15/02/2017 08:04:39 pm To: dev@river.apache.org Subject: Re: deserialization remote invocation strategy The code actually does what I've described above, but don't take my word for it, check it for youself. :) If you disagree, don't use it. It works the other way around - before I decide to use it - I have to understand how it works. Even more so if we are talking about security. That is why I consider scrutiny and questioning a Good Thing in this context. "Check for yourself" is not an encouraging advice in the area of security :) Cheers, Michal
Re: deserialization remote invocation strategy
Ok, Will see what I can do over the weekend. For users already familiar with River, there's not much new as it's mostly abstracted behind ServiceDiscoveryManager, LookupCache' ProxyPreparer and ServiceItemFilter. The non trivial part is implementing AtomicSerial. An introduction to AtomicSerial is available on the jgdms wiki. Regards, Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek Sent: 15/02/2017 09:07:33 pm To: dev@river.apache.org Subject: Re: deserialization remote invocation strategy Reviewing just the source code without any high level overview and explanation how and why it is implemented in a particular way is difficult (if possible at all). That is why it would be really helpful if the questions asked were answered. Not only researchers are interested - also potential users and contributors. Thanks, Michal Peter wrote: > I can't make any guarantee that it is secure, but the more people review it, >the more likelihood bugs and flaws will be identified. > > I'm especially interested in security researchers checking it out if they're >interested. > > Cheers, > > Peter. > > Sent from my Samsung device. > >Include original message > Original message > From: Michał Kłeczek > Sent: 15/02/2017 08:04:39 pm > To: dev@river.apache.org > Subject: Re: deserialization remote invocation strategy > > >> The code actually does what I've described above, but don't take my word >>for it, check it for youself. :) >> >> If you disagree, don't use it. > It works the other way around - before I decide to use it - I have to > understand how it works. > Even more so if we are talking about security. > > That is why I consider scrutiny and questioning a Good Thing in this > context. > > "Check for yourself" is not an encouraging advice in the area of security :) > > Cheers, > Michal > > >
Re: deserialization remote invocation strategy
Thanks Pat, I'd appreciate that. I've documentation, but there's no single document at present. Do you think a draft revision of the Jini specifications documenting the additions would be sufficient? Regards, Peter. Sent from my Samsung device. Include original message Original message From: Patricia Shanahan Sent: 15/02/2017 09:18:46 pm To: dev@river.apache.org Subject: Re: deserialization remote invocation strategy I still have some contacts into the UCSD computer science department from when I was doing my PhD. If we had a stated security model, it might be worth asking whether any students are interested in reviewing it. On 2/15/2017 3:07 AM, Michał Kłeczek wrote: > Reviewing just the source code without any high level overview and > explanation how and why it is implemented in a particular way > is difficult (if possible at all). > > That is why it would be really helpful if the questions asked were > answered. > > Not only researchers are interested - also potential users and > contributors. > > Thanks, > Michal > > Peter wrote: >> I can't make any guarantee that it is secure, but the more people >> review it, the more likelihood bugs and flaws will be identified. >> >> I'm especially interested in security researchers checking it out if >> they're interested. >> >> Cheers, >> >> Peter. >> >> Sent from my Samsung device. >> Include original message >> Original message >> From: Michał Kłeczek >> Sent: 15/02/2017 08:04:39 pm >> To: dev@river.apache.org >> Subject: Re: deserialization remote invocation strategy >> >> >>> The code actually does what I've described above, but don't take my >>> word for it, check it for youself. :) >>> >>> If you disagree, don't use it. >> It works the other way around - before I decide to use it - I have to >> understand how it works. >> Even more so if we are talking about security. >> >> That is why I consider scrutiny and questioning a Good Thing in this >> context. >> >> "Check for yourself" is not an encouraging advice in the area of >> security :) >> >> Cheers, >> Michal >> >> >> > >
