Re: [PROPOSAL]: Improve OQL Method Invocation Security

+1 I just re-reviewed this proposal and it looks good to me. - Aaron > On Jul 12, 2019, at 6:29 AM, Juan José Ramos wrote: > > Hello Mike, > > Agreed, we'll probably need to create an enhancement request for this > feature in JIRA. > Cheers. > > On Thu, Jul 11, 2019 at 5:37 PM Michael Stolz

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello Mike, Agreed, we'll probably need to create an enhancement request for this feature in JIRA. Cheers. On Thu, Jul 11, 2019 at 5:37 PM Michael Stolz wrote: > One thing I will mention regarding DATA:READ:RegionName allowing query > behavior is that we have been asked by some users already to

Re: [PROPOSAL]: Improve OQL Method Invocation Security

One thing I will mention regarding DATA:READ:RegionName allowing query behavior is that we have been asked by some users already to separate DATA:READ:RegionName from DATA:QUERY:RegionName. This request is to protect against arbitrary query execution by administrators that can cause huge resource c

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello all, Friendly reminder regarding the deadline to rise concerns and/or objections regarding the *OQL Method InvocationSecurity Proposal [1]*, I'll go ahead and move it to *Development* on July 13th. Best regards. [1]: https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Se

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Done [1]!. Please remember that, if no major concerns arise before Friday this week, I'll go ahead and move the proposal to *Development* on July 13th. Best regards. [1]: https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-PriorArt On Fri,

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Can you please add a Prior Art section to your proposal discussing these alternative solutions and why they are insufficient? Thanks, Jake > On Jul 5, 2019, at 10:41 AM, Juan José Ramos wrote: > > Hello Jake, > > I've replied something similar *here [1]*. > Long story short, I haven't found

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello Jake, I've replied something similar *here [1]*. Long story short, I haven't found anything that really applies to our use case. The "most similar solution" is *Spring Method Security [2]*, which basically implies annotating methods with explicit configuration about the roles required to exe

Re: [PROPOSAL]: Improve OQL Method Invocation Security

So if we don’t want to use the Java built in SecurityManager to solve this, because we feel it's too big or too inflexible for our needs, have other projects implemented something we can borrow? We can’t be the first to need something like this if Java’s solution isn’t a good fit. Again I want

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello all, If you haven't added my email to the spam folder already :-), then I'd like to let you know that I've update again the *Proposal [1]* and incorporated most of the feedback provided, along with some additional information and context I missed on the previous versions, thanks all that bro

Re: [PROPOSAL]: Improve OQL Method Invocation Security

With Juan's proposal, the user still has the option to use java's security manager. They can install a MethodAuthorizor that allows all methods and use a java SecurityManager to restrict method access to the methods they want. Regarding the question of "How far should we go to prevent users from s

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello, Thanks for the feedback provided so far. I'm still resilient to add the *Java Security Manager* as an option, maybe it's due to my lack of experience around the subject but I still believe it is killing mosquitoes with a bazooka. We need to prevent this "bad things" only from within the OQL

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Are security manager policies modifiable on the fly? Just wondering if someone decides they want to disallow or allow something, will they need to restart their vms/geode node? I think Dan pointed this out earlier in the thread, but just wanted to have us consider the original cve that led to the

Re: [PROPOSAL]: Improve OQL Method Invocation Security

> On Jul 2, 2019, at 11:58 AM, Juan José Ramos wrote: > > Hello Jake, > > I've been doing some reading about the *Java Security Manager* and, even > when it might work for our use case, I don't think is a good fit due to the > following reasons: > 1). We already have chosen *Shiro* for authen

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello Jake, I've been doing some reading about the *Java Security Manager* and, even when it might work for our use case, I don't think is a good fit due to the following reasons: 1). We already have chosen *Shiro* for authentication and authorization, adding yet another security framework (and ma

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello Jake, Thanks for your reply. Some comments below, inline. *>> Premature optimization can be bad but so can ignoring it. Most importantly here is to define the scope of an authorization. This will need to be defined as part of the API/SPI. If I was to implement one of these authorizers I wou

Re: [PROPOSAL]: Improve OQL Method Invocation Security

> On Jul 1, 2019, at 6:55 AM, Juan José Ramos wrote: > >> Can we safely assume that some caching of authorization requests will >> be performed? What will the scope and lifetime of this caching be? Are the >> authentication rules and modules assumed to be immutable at runtime? All of >> this w

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello Jake, *>> You asked people to comment in both the wiki and the emails but you didn’t include comments from the wiki below.* I never said I was going to reply to comments in the wiki and to the email thread at the same time on the same day. I didn't forget your comments, BTW, I was going to a

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Juan, You asked people to comment in both the wiki and the emails but you didn’t include comments from the wiki below. I have two issues, the first I raised in the wiki is what about caching the authentication lookups: > Can we safely assume that some caching of authorization requests will be

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello all, Below are some answers/comments to the questions and feedback gathered during the last round, along with some final ideas at the end of the email. [Aaron]: There is almost always trade-off between security and ease-of-use. The pr

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Helo all, Thanks for all the feedback. I'll go over the comments and reply accordingly, hopefully between tomorrow and Friday. Best regards. On Wed, Jun 26, 2019 at 2:12 PM Dan Smith wrote: > A couple of other things to keep in mind to make sure you aren't > introducing security holes > > 1)

Re: [PROPOSAL]: Improve OQL Method Invocation Security

A couple of other things to keep in mind to make sure you aren't introducing security holes 1) Queries can be executed by users with read privileges. So if it needs to be really clear to the operator whether the MethodInvocationAuthorizer they are configuring is going to let users call methods tha

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Here are the things I think are important: 1) I shouldn’t have to change my domain classes in order to run a query. 2) I shouldn’t have to configure anything to run a “normal” query that uses classes deployed into the cluster and stored in the region. 3) By default the cluster is secure from mali

Re: [PROPOSAL]: Improve OQL Method Invocation Security

+1 to the proposal Some comments: - There is almost always trade-off between security and ease-of-use. The proposed implementation of JavaBeanAccessorBasedMethodAuthorizer makes me feel uneasy because it would be super easy to create a method that begins with "get" or "is" but is not

Re: [PROPOSAL]: Improve OQL Method Invocation Security

+1 I have some concerns about all of the different ways we configure geode to be secure, but that's a different issue ;-) Overall, very thorough proposal Juan! On Mon, Jun 24, 2019 at 4:22 PM Dan Smith wrote: > +1 > > This proposal looks good to me! > > On Mon, Jun 24, 2019 at 4:15 PM Udo Koh

Re: [PROPOSAL]: Improve OQL Method Invocation Security

+1 This proposal looks good to me! On Mon, Jun 24, 2019 at 4:15 PM Udo Kohlmeyer wrote: > +1, Count me in > > On 6/24/19 13:06, Juan José Ramos wrote: > > Hey Jake, > > > > Sure, I guess we could do a live session if there's enough interest after > > people have reviewed the proposal. > > Best

Re: [PROPOSAL]: Improve OQL Method Invocation Security

+1, Count me in On 6/24/19 13:06, Juan José Ramos wrote: Hey Jake, Sure, I guess we could do a live session if there's enough interest after people have reviewed the proposal. Best regards. On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett wrote: On Jun 24, 2019, at 11:49 AM, Juan José Ramos

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hey Jake, Sure, I guess we could do a live session if there's enough interest after people have reviewed the proposal. Best regards. On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett wrote: > > > > On Jun 24, 2019, at 11:49 AM, Juan José Ramos wrote: > > > > I’d rather get feedback in any way and

Re: [PROPOSAL]: Improve OQL Method Invocation Security

> On Jun 24, 2019, at 11:49 AM, Juan José Ramos wrote: > > I’d rather get feedback in any way and aggregate everything on my own than > maybe not getting anything because I'm explicitly limiting the options to > provide it. Dealers choice so both it is! Could you also consider public live s

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hey Jake, It makes sense. I personally prefer to gather feedback through the Wiki to keep everything in one single place, *but* I've explicitly mentioned the two options as acceptable because this particular proposal already got feedback through both communication channels *and* we haven't settled

Re: [PROPOSAL]: Improve OQL Method Invocation Security

> On Jun 24, 2019, at 11:35 AM, Juan José Ramos wrote: > > Please take some time to review it thoroughly, adding comments and/or > concerns either to the *Wiki page [1]* or this email thread directly, all > feedback is more than welcome. Let’s try to keep the conversation in one medium or the o

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello all, I've update the *Proposal [1]* incorporating the feedback provided. Please take some time to review it thoroughly, adding comments and/or concerns either to the *Wiki page [1]* or this email thread directly, all feedback is more than welcome. I'll reach out again in one week time with a

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello Dan, Thanks a lot for the feedback!. Please find my answers below. (1). Great point, I totally missed this one... I wrongly assumed that *this particular method [1]* was in charge of authorizing the query execution on the region but I was clearly wrong, the actual authorization happens *her

Re: [PROPOSAL]: Improve OQL Method Invocation Security

+1 This looks really good! I put a couple of comments inline, and I have a few more general questions here: 1. Is the RegionQueryInvocationAuthorizer different than our existing shiro permissions? I thought users can already grant permissions for specific regions. What does this add in addition t

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Thanks Juan! > On Jun 19, 2019, at 9:55 AM, Juan José Ramos wrote: > > Hello all, > > I've removed all "biased" words I could find from the original document so > the *Proposal [1]* is ready for review and discussion now. All feedback is > welcome. > Best regards. > > [1]: > https://cwiki.apac

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hello all, I've removed all "biased" words I could find from the original document so the *Proposal [1]* is ready for review and discussion now. All feedback is welcome. Best regards. [1]: https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security On Fri, Jun 14, 2019 at 8:

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Hey Jake, Thanks for bringing this up. As you might have found out already, english is not my native language, I actually had to do some research to find out *exactly what you meant* regarding the bias around the "whitelist" word :-|... It was an honest mistake and I sincerely apologize in advance

Re: [PROPOSAL]: Improve OQL Method Invocation Security

> As part of GEODE-3247 , > several options were analysed and, after considering the wealth of security > holes and the difficulty of determining which methods deployed by the > developer were intended to be available for queries and which were n

[PROPOSAL]: Improve OQL Method Invocation Security

Hello everyone, I've just published in the Wiki a new proposal to improve the current behaviour regarding how we allow/deny certain method to be invoked on objects as part of the OQL execution. It's still in early s