You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by "Ju@N" <ju...@gmail.com> on 2019/06/14 22:36:27 UTC
[PROPOSAL]: Improve OQL Method Invocation Security
Hello everyone,
I've just published in the Wiki a new proposal
<https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security>
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
stages and some of the suggested implementations might not even be
possible, but please go ahead and submit any feedback and/or ideas you
might have about it, every contribution is welcome.
Best regards.
--
Ju@N
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Aaron Lindsey <al...@pivotal.io>.
+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 <jr...@pivotal.io> 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 <ms...@pivotal.io> wrote:
>
>> 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 consumption.
>>
>> So regardless of all the rest of the proposal, that's something we should
>> probably consider standardizing on.
>>
>> --
>> Mike Stolz
>> Principal Engineer, Pivotal Cloud Cache
>> Mobile: +1-631-835-4771
>>
>>
>>
>> On Thu, Jul 11, 2019 at 11:36 AM Juan José Ramos <jr...@pivotal.io>
>> wrote:
>>
>>> 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+Security#OQLMethodInvocationSecurity-PriorArt
>>>
>>>
>>> On Mon, Jul 8, 2019 at 3:29 PM Juan José Ramos <jr...@pivotal.io>
>> wrote:
>>>
>>>> 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, Jul 5, 2019 at 3:48 PM Jacob Barrett <jb...@pivotal.io>
>>> wrote:
>>>>
>>>>> 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 <jr...@pivotal.io>
>>> wrote:
>>>>>>
>>>>>> 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 execute them. The same goes for *Shiro
>>>>> **Annotation-based
>>>>>> Authorization [3]*. The *AnnotationBasedMethodAuthorize**r [3]*
>>> approach
>>>>>> from the proposal is somewhat similar to this, but I've discarded it
>>>>>> because if forces the user to annotate classes with our own
>>> annotations,
>>>>>> basically forcing them to modify their domain model.
>>>>>> The proposal basically allows our users to use one of the default of
>>> the
>>>>>> box implementations and, if they don't like them for whatever
>> reason,
>>> is
>>>>>> flexible enough so they can ultimately provide their own.
>>>>>> Hope this helps.
>>>>>> Cheers.
>>>>>>
>>>>>> [1]:
>>>>>>
>>>>>
>>>
>> https://markmail.org/message/ekons7ixtz4jtf7n#query:+page:1+mid:snxgpsqd3yuppmsc+state:results
>>>>>> [2]:
>>>>>>
>>>>>
>>>
>> https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
>>>>>> [3]:
>>>>>>
>>>>>
>>>
>> https://shiro.apache.org/authorization.html#Authorization-AnnotationbasedAuthorization
>>>>>> [4]:
>>>>>>
>>>>>
>>>
>> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer
>>>>>>
>>>>>> On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett <jb...@pivotal.io>
>>>>> wrote:
>>>>>>
>>>>>>> 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 to avoid inventing something new. What prior art is
>> out
>>>>> there?
>>>>>>>
>>>>>>>
>>>>>>>> On Jul 4, 2019, at 1:29 PM, Juan José Ramos <jr...@pivotal.io>
>>>>> wrote:
>>>>>>>>
>>>>>>>> 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 brought
>>>>>>> concerns
>>>>>>>> and suggestions to the discussion. Please take some time to review
>>> it
>>>>>>>> thoroughly, adding comments and/or concerns *only on this email
>>>>> thread*,
>>>>>>>> all feedback is more than welcome.
>>>>>>>> If no major concerns arise before July 12th 2019, I'll go ahead
>> and
>>>>> mark
>>>>>>>> move the proposal to *Development* on July 13th.
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> [1]:
>>>>>>>>
>>>>>>>
>>>>>
>>>
>> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Juan José Ramos Cassella
>>>>>> Senior Technical Support Engineer
>>>>>> Email: jramos@pivotal.io
>>>>>> Office#: +353 21 4238611
>>>>>> Mobile#: +353 87 2074066
>>>>>> After Hours Contact#: +1 877 477 2269
>>>>>> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
>>>>>> How to upload artifacts:
>>>>>> https://support.pivotal.io/hc/en-us/articles/204369073
>>>>>> How to escalate a ticket:
>>>>>> https://support.pivotal.io/hc/en-us/articles/203809556
>>>>>>
>>>>>> [image: support] <https://support.pivotal.io/> [image: twitter]
>>>>>> <https://twitter.com/pivotal> [image: linkedin]
>>>>>> <https://www.linkedin.com/company/3048967> [image: facebook]
>>>>>> <https://www.facebook.com/pivotalsoftware> [image: google plus]
>>>>>> <https://plus.google.com/+Pivotal> [image: youtube]
>>>>>> <
>>>>>
>>> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl
>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Juan José Ramos Cassella
>>>> Senior Technical Support Engineer
>>>> Email: jramos@pivotal.io
>>>> Office#: +353 21 4238611
>>>> Mobile#: +353 87 2074066
>>>> After Hours Contact#: +1 877 477 2269
>>>> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
>>>> How to upload artifacts:
>>>> https://support.pivotal.io/hc/en-us/articles/204369073
>>>> How to escalate a ticket:
>>>> https://support.pivotal.io/hc/en-us/articles/203809556
>>>>
>>>> [image: support] <https://support.pivotal.io/> [image: twitter]
>>>> <https://twitter.com/pivotal> [image: linkedin]
>>>> <https://www.linkedin.com/company/3048967> [image: facebook]
>>>> <https://www.facebook.com/pivotalsoftware> [image: google plus]
>>>> <https://plus.google.com/+Pivotal> [image: youtube]
>>>> <
>>> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl
>>>
>>>>
>>>
>>>
>>> --
>>> Juan José Ramos Cassella
>>> Senior Technical Support Engineer
>>> Email: jramos@pivotal.io
>>> Office#: +353 21 4238611
>>> Mobile#: +353 87 2074066
>>> After Hours Contact#: +1 877 477 2269
>>> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
>>> How to upload artifacts:
>>> https://support.pivotal.io/hc/en-us/articles/204369073
>>> How to escalate a ticket:
>>> https://support.pivotal.io/hc/en-us/articles/203809556
>>>
>>> [image: support] <https://support.pivotal.io/> [image: twitter]
>>> <https://twitter.com/pivotal> [image: linkedin]
>>> <https://www.linkedin.com/company/3048967> [image: facebook]
>>> <https://www.facebook.com/pivotalsoftware> [image: google plus]
>>> <https://plus.google.com/+Pivotal> [image: youtube]
>>> <
>> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>>>
>>
>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 <ms...@pivotal.io> wrote:
> 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 consumption.
>
> So regardless of all the rest of the proposal, that's something we should
> probably consider standardizing on.
>
> --
> Mike Stolz
> Principal Engineer, Pivotal Cloud Cache
> Mobile: +1-631-835-4771
>
>
>
> On Thu, Jul 11, 2019 at 11:36 AM Juan José Ramos <jr...@pivotal.io>
> wrote:
>
> > 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+Security#OQLMethodInvocationSecurity-PriorArt
> >
> >
> > On Mon, Jul 8, 2019 at 3:29 PM Juan José Ramos <jr...@pivotal.io>
> wrote:
> >
> > > 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, Jul 5, 2019 at 3:48 PM Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > >
> > >> 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 <jr...@pivotal.io>
> > wrote:
> > >> >
> > >> > 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 execute them. The same goes for *Shiro
> > >> **Annotation-based
> > >> > Authorization [3]*. The *AnnotationBasedMethodAuthorize**r [3]*
> > approach
> > >> > from the proposal is somewhat similar to this, but I've discarded it
> > >> > because if forces the user to annotate classes with our own
> > annotations,
> > >> > basically forcing them to modify their domain model.
> > >> > The proposal basically allows our users to use one of the default of
> > the
> > >> > box implementations and, if they don't like them for whatever
> reason,
> > is
> > >> > flexible enough so they can ultimately provide their own.
> > >> > Hope this helps.
> > >> > Cheers.
> > >> >
> > >> > [1]:
> > >> >
> > >>
> >
> https://markmail.org/message/ekons7ixtz4jtf7n#query:+page:1+mid:snxgpsqd3yuppmsc+state:results
> > >> > [2]:
> > >> >
> > >>
> >
> https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
> > >> > [3]:
> > >> >
> > >>
> >
> https://shiro.apache.org/authorization.html#Authorization-AnnotationbasedAuthorization
> > >> > [4]:
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer
> > >> >
> > >> > On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett <jb...@pivotal.io>
> > >> wrote:
> > >> >
> > >> >> 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 to avoid inventing something new. What prior art is
> out
> > >> there?
> > >> >>
> > >> >>
> > >> >>> On Jul 4, 2019, at 1:29 PM, Juan José Ramos <jr...@pivotal.io>
> > >> wrote:
> > >> >>>
> > >> >>> 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 brought
> > >> >> concerns
> > >> >>> and suggestions to the discussion. Please take some time to review
> > it
> > >> >>> thoroughly, adding comments and/or concerns *only on this email
> > >> thread*,
> > >> >>> all feedback is more than welcome.
> > >> >>> If no major concerns arise before July 12th 2019, I'll go ahead
> and
> > >> mark
> > >> >>> move the proposal to *Development* on July 13th.
> > >> >>> Best regards.
> > >> >>>
> > >> >>> [1]:
> > >> >>>
> > >> >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
> > >> >>
> > >> >>
> > >> >
> > >> > --
> > >> > Juan José Ramos Cassella
> > >> > Senior Technical Support Engineer
> > >> > Email: jramos@pivotal.io
> > >> > Office#: +353 21 4238611
> > >> > Mobile#: +353 87 2074066
> > >> > After Hours Contact#: +1 877 477 2269
> > >> > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > >> > How to upload artifacts:
> > >> > https://support.pivotal.io/hc/en-us/articles/204369073
> > >> > How to escalate a ticket:
> > >> > https://support.pivotal.io/hc/en-us/articles/203809556
> > >> >
> > >> > [image: support] <https://support.pivotal.io/> [image: twitter]
> > >> > <https://twitter.com/pivotal> [image: linkedin]
> > >> > <https://www.linkedin.com/company/3048967> [image: facebook]
> > >> > <https://www.facebook.com/pivotalsoftware> [image: google plus]
> > >> > <https://plus.google.com/+Pivotal> [image: youtube]
> > >> > <
> > >>
> > https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl
> >
> > >>
> > >>
> > >
> > > --
> > > Juan José Ramos Cassella
> > > Senior Technical Support Engineer
> > > Email: jramos@pivotal.io
> > > Office#: +353 21 4238611
> > > Mobile#: +353 87 2074066
> > > After Hours Contact#: +1 877 477 2269
> > > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > > How to upload artifacts:
> > > https://support.pivotal.io/hc/en-us/articles/204369073
> > > How to escalate a ticket:
> > > https://support.pivotal.io/hc/en-us/articles/203809556
> > >
> > > [image: support] <https://support.pivotal.io/> [image: twitter]
> > > <https://twitter.com/pivotal> [image: linkedin]
> > > <https://www.linkedin.com/company/3048967> [image: facebook]
> > > <https://www.facebook.com/pivotalsoftware> [image: google plus]
> > > <https://plus.google.com/+Pivotal> [image: youtube]
> > > <
> > https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl
> >
> > >
> >
> >
> > --
> > Juan José Ramos Cassella
> > Senior Technical Support Engineer
> > Email: jramos@pivotal.io
> > Office#: +353 21 4238611
> > Mobile#: +353 87 2074066
> > After Hours Contact#: +1 877 477 2269
> > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > How to upload artifacts:
> > https://support.pivotal.io/hc/en-us/articles/204369073
> > How to escalate a ticket:
> > https://support.pivotal.io/hc/en-us/articles/203809556
> >
> > [image: support] <https://support.pivotal.io/> [image: twitter]
> > <https://twitter.com/pivotal> [image: linkedin]
> > <https://www.linkedin.com/company/3048967> [image: facebook]
> > <https://www.facebook.com/pivotalsoftware> [image: google plus]
> > <https://plus.google.com/+Pivotal> [image: youtube]
> > <
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
> >
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Michael Stolz <ms...@pivotal.io>.
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 consumption.
So regardless of all the rest of the proposal, that's something we should
probably consider standardizing on.
--
Mike Stolz
Principal Engineer, Pivotal Cloud Cache
Mobile: +1-631-835-4771
On Thu, Jul 11, 2019 at 11:36 AM Juan José Ramos <jr...@pivotal.io> wrote:
> 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+Security#OQLMethodInvocationSecurity-PriorArt
>
>
> On Mon, Jul 8, 2019 at 3:29 PM Juan José Ramos <jr...@pivotal.io> wrote:
>
> > 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, Jul 5, 2019 at 3:48 PM Jacob Barrett <jb...@pivotal.io>
> wrote:
> >
> >> 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 <jr...@pivotal.io>
> wrote:
> >> >
> >> > 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 execute them. The same goes for *Shiro
> >> **Annotation-based
> >> > Authorization [3]*. The *AnnotationBasedMethodAuthorize**r [3]*
> approach
> >> > from the proposal is somewhat similar to this, but I've discarded it
> >> > because if forces the user to annotate classes with our own
> annotations,
> >> > basically forcing them to modify their domain model.
> >> > The proposal basically allows our users to use one of the default of
> the
> >> > box implementations and, if they don't like them for whatever reason,
> is
> >> > flexible enough so they can ultimately provide their own.
> >> > Hope this helps.
> >> > Cheers.
> >> >
> >> > [1]:
> >> >
> >>
> https://markmail.org/message/ekons7ixtz4jtf7n#query:+page:1+mid:snxgpsqd3yuppmsc+state:results
> >> > [2]:
> >> >
> >>
> https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
> >> > [3]:
> >> >
> >>
> https://shiro.apache.org/authorization.html#Authorization-AnnotationbasedAuthorization
> >> > [4]:
> >> >
> >>
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer
> >> >
> >> > On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett <jb...@pivotal.io>
> >> wrote:
> >> >
> >> >> 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 to avoid inventing something new. What prior art is out
> >> there?
> >> >>
> >> >>
> >> >>> On Jul 4, 2019, at 1:29 PM, Juan José Ramos <jr...@pivotal.io>
> >> wrote:
> >> >>>
> >> >>> 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 brought
> >> >> concerns
> >> >>> and suggestions to the discussion. Please take some time to review
> it
> >> >>> thoroughly, adding comments and/or concerns *only on this email
> >> thread*,
> >> >>> all feedback is more than welcome.
> >> >>> If no major concerns arise before July 12th 2019, I'll go ahead and
> >> mark
> >> >>> move the proposal to *Development* on July 13th.
> >> >>> Best regards.
> >> >>>
> >> >>> [1]:
> >> >>>
> >> >>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
> >> >>
> >> >>
> >> >
> >> > --
> >> > Juan José Ramos Cassella
> >> > Senior Technical Support Engineer
> >> > Email: jramos@pivotal.io
> >> > Office#: +353 21 4238611
> >> > Mobile#: +353 87 2074066
> >> > After Hours Contact#: +1 877 477 2269
> >> > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> >> > How to upload artifacts:
> >> > https://support.pivotal.io/hc/en-us/articles/204369073
> >> > How to escalate a ticket:
> >> > https://support.pivotal.io/hc/en-us/articles/203809556
> >> >
> >> > [image: support] <https://support.pivotal.io/> [image: twitter]
> >> > <https://twitter.com/pivotal> [image: linkedin]
> >> > <https://www.linkedin.com/company/3048967> [image: facebook]
> >> > <https://www.facebook.com/pivotalsoftware> [image: google plus]
> >> > <https://plus.google.com/+Pivotal> [image: youtube]
> >> > <
> >>
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
> >>
> >>
> >
> > --
> > Juan José Ramos Cassella
> > Senior Technical Support Engineer
> > Email: jramos@pivotal.io
> > Office#: +353 21 4238611
> > Mobile#: +353 87 2074066
> > After Hours Contact#: +1 877 477 2269
> > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > How to upload artifacts:
> > https://support.pivotal.io/hc/en-us/articles/204369073
> > How to escalate a ticket:
> > https://support.pivotal.io/hc/en-us/articles/203809556
> >
> > [image: support] <https://support.pivotal.io/> [image: twitter]
> > <https://twitter.com/pivotal> [image: linkedin]
> > <https://www.linkedin.com/company/3048967> [image: facebook]
> > <https://www.facebook.com/pivotalsoftware> [image: google plus]
> > <https://plus.google.com/+Pivotal> [image: youtube]
> > <
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
> >
>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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+Security#OQLMethodInvocationSecurity-PriorArt
On Mon, Jul 8, 2019 at 3:29 PM Juan José Ramos <jr...@pivotal.io> wrote:
> 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, Jul 5, 2019 at 3:48 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>> 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 <jr...@pivotal.io> wrote:
>> >
>> > 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 execute them. The same goes for *Shiro
>> **Annotation-based
>> > Authorization [3]*. The *AnnotationBasedMethodAuthorize**r [3]* approach
>> > from the proposal is somewhat similar to this, but I've discarded it
>> > because if forces the user to annotate classes with our own annotations,
>> > basically forcing them to modify their domain model.
>> > The proposal basically allows our users to use one of the default of the
>> > box implementations and, if they don't like them for whatever reason, is
>> > flexible enough so they can ultimately provide their own.
>> > Hope this helps.
>> > Cheers.
>> >
>> > [1]:
>> >
>> https://markmail.org/message/ekons7ixtz4jtf7n#query:+page:1+mid:snxgpsqd3yuppmsc+state:results
>> > [2]:
>> >
>> https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
>> > [3]:
>> >
>> https://shiro.apache.org/authorization.html#Authorization-AnnotationbasedAuthorization
>> > [4]:
>> >
>> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer
>> >
>> > On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett <jb...@pivotal.io>
>> wrote:
>> >
>> >> 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 to avoid inventing something new. What prior art is out
>> there?
>> >>
>> >>
>> >>> On Jul 4, 2019, at 1:29 PM, Juan José Ramos <jr...@pivotal.io>
>> wrote:
>> >>>
>> >>> 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 brought
>> >> concerns
>> >>> and suggestions to the discussion. Please take some time to review it
>> >>> thoroughly, adding comments and/or concerns *only on this email
>> thread*,
>> >>> all feedback is more than welcome.
>> >>> If no major concerns arise before July 12th 2019, I'll go ahead and
>> mark
>> >>> move the proposal to *Development* on July 13th.
>> >>> Best regards.
>> >>>
>> >>> [1]:
>> >>>
>> >>
>> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
>> >>
>> >>
>> >
>> > --
>> > Juan José Ramos Cassella
>> > Senior Technical Support Engineer
>> > Email: jramos@pivotal.io
>> > Office#: +353 21 4238611
>> > Mobile#: +353 87 2074066
>> > After Hours Contact#: +1 877 477 2269
>> > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
>> > How to upload artifacts:
>> > https://support.pivotal.io/hc/en-us/articles/204369073
>> > How to escalate a ticket:
>> > https://support.pivotal.io/hc/en-us/articles/203809556
>> >
>> > [image: support] <https://support.pivotal.io/> [image: twitter]
>> > <https://twitter.com/pivotal> [image: linkedin]
>> > <https://www.linkedin.com/company/3048967> [image: facebook]
>> > <https://www.facebook.com/pivotalsoftware> [image: google plus]
>> > <https://plus.google.com/+Pivotal> [image: youtube]
>> > <
>> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>>
>>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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, Jul 5, 2019 at 3:48 PM Jacob Barrett <jb...@pivotal.io> wrote:
> 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 <jr...@pivotal.io> wrote:
> >
> > 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 execute them. The same goes for *Shiro
> **Annotation-based
> > Authorization [3]*. The *AnnotationBasedMethodAuthorize**r [3]* approach
> > from the proposal is somewhat similar to this, but I've discarded it
> > because if forces the user to annotate classes with our own annotations,
> > basically forcing them to modify their domain model.
> > The proposal basically allows our users to use one of the default of the
> > box implementations and, if they don't like them for whatever reason, is
> > flexible enough so they can ultimately provide their own.
> > Hope this helps.
> > Cheers.
> >
> > [1]:
> >
> https://markmail.org/message/ekons7ixtz4jtf7n#query:+page:1+mid:snxgpsqd3yuppmsc+state:results
> > [2]:
> >
> https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
> > [3]:
> >
> https://shiro.apache.org/authorization.html#Authorization-AnnotationbasedAuthorization
> > [4]:
> >
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer
> >
> > On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett <jb...@pivotal.io>
> wrote:
> >
> >> 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 to avoid inventing something new. What prior art is out
> there?
> >>
> >>
> >>> On Jul 4, 2019, at 1:29 PM, Juan José Ramos <jr...@pivotal.io> wrote:
> >>>
> >>> 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 brought
> >> concerns
> >>> and suggestions to the discussion. Please take some time to review it
> >>> thoroughly, adding comments and/or concerns *only on this email
> thread*,
> >>> all feedback is more than welcome.
> >>> If no major concerns arise before July 12th 2019, I'll go ahead and
> mark
> >>> move the proposal to *Development* on July 13th.
> >>> Best regards.
> >>>
> >>> [1]:
> >>>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
> >>
> >>
> >
> > --
> > Juan José Ramos Cassella
> > Senior Technical Support Engineer
> > Email: jramos@pivotal.io
> > Office#: +353 21 4238611
> > Mobile#: +353 87 2074066
> > After Hours Contact#: +1 877 477 2269
> > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > How to upload artifacts:
> > https://support.pivotal.io/hc/en-us/articles/204369073
> > How to escalate a ticket:
> > https://support.pivotal.io/hc/en-us/articles/203809556
> >
> > [image: support] <https://support.pivotal.io/> [image: twitter]
> > <https://twitter.com/pivotal> [image: linkedin]
> > <https://www.linkedin.com/company/3048967> [image: facebook]
> > <https://www.facebook.com/pivotalsoftware> [image: google plus]
> > <https://plus.google.com/+Pivotal> [image: youtube]
> > <
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <jr...@pivotal.io> wrote:
>
> 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 execute them. The same goes for *Shiro **Annotation-based
> Authorization [3]*. The *AnnotationBasedMethodAuthorize**r [3]* approach
> from the proposal is somewhat similar to this, but I've discarded it
> because if forces the user to annotate classes with our own annotations,
> basically forcing them to modify their domain model.
> The proposal basically allows our users to use one of the default of the
> box implementations and, if they don't like them for whatever reason, is
> flexible enough so they can ultimately provide their own.
> Hope this helps.
> Cheers.
>
> [1]:
> https://markmail.org/message/ekons7ixtz4jtf7n#query:+page:1+mid:snxgpsqd3yuppmsc+state:results
> [2]:
> https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
> [3]:
> https://shiro.apache.org/authorization.html#Authorization-AnnotationbasedAuthorization
> [4]:
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer
>
> On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>> 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 to avoid inventing something new. What prior art is out there?
>>
>>
>>> On Jul 4, 2019, at 1:29 PM, Juan José Ramos <jr...@pivotal.io> wrote:
>>>
>>> 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 brought
>> concerns
>>> and suggestions to the discussion. Please take some time to review it
>>> thoroughly, adding comments and/or concerns *only on this email thread*,
>>> all feedback is more than welcome.
>>> If no major concerns arise before July 12th 2019, I'll go ahead and mark
>>> move the proposal to *Development* on July 13th.
>>> Best regards.
>>>
>>> [1]:
>>>
>> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
>>
>>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 execute them. The same goes for *Shiro **Annotation-based
Authorization [3]*. The *AnnotationBasedMethodAuthorize**r [3]* approach
from the proposal is somewhat similar to this, but I've discarded it
because if forces the user to annotate classes with our own annotations,
basically forcing them to modify their domain model.
The proposal basically allows our users to use one of the default of the
box implementations and, if they don't like them for whatever reason, is
flexible enough so they can ultimately provide their own.
Hope this helps.
Cheers.
[1]:
https://markmail.org/message/ekons7ixtz4jtf7n#query:+page:1+mid:snxgpsqd3yuppmsc+state:results
[2]:
https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
[3]:
https://shiro.apache.org/authorization.html#Authorization-AnnotationbasedAuthorization
[4]:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer
On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett <jb...@pivotal.io> wrote:
> 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 to avoid inventing something new. What prior art is out there?
>
>
> > On Jul 4, 2019, at 1:29 PM, Juan José Ramos <jr...@pivotal.io> wrote:
> >
> > 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 brought
> concerns
> > and suggestions to the discussion. Please take some time to review it
> > thoroughly, adding comments and/or concerns *only on this email thread*,
> > all feedback is more than welcome.
> > If no major concerns arise before July 12th 2019, I'll go ahead and mark
> > move the proposal to *Development* on July 13th.
> > Best regards.
> >
> > [1]:
> >
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jacob Barrett <jb...@pivotal.io>.
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 to avoid inventing something new. What prior art is out there?
> On Jul 4, 2019, at 1:29 PM, Juan José Ramos <jr...@pivotal.io> wrote:
>
> 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 brought concerns
> and suggestions to the discussion. Please take some time to review it
> thoroughly, adding comments and/or concerns *only on this email thread*,
> all feedback is more than welcome.
> If no major concerns arise before July 12th 2019, I'll go ahead and mark
> move the proposal to *Development* on July 13th.
> Best regards.
>
> [1]:
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 brought concerns
and suggestions to the discussion. Please take some time to review it
thoroughly, adding comments and/or concerns *only on this email thread*,
all feedback is more than welcome.
If no major concerns arise before July 12th 2019, I'll go ahead and mark
move the proposal to *Development* on July 13th.
Best regards.
[1]:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
On Wed, Jul 3, 2019 at 3:22 PM Dan Smith <ds...@pivotal.io> wrote:
> 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
> shooting themselves in the foot?" I think we do need to honor the security
> policies that administrators have configured for geode. Since we allow the
> administrators to configure the system to give certain users READ but not
> WRITE access, it's on us to make sure those users are not allowed to modify
> the data. If users with READ access can modify data, that is a security
> vulnerability in Geode.
>
> -Dan
>
>
> On Wed, Jul 3, 2019 at 8:33 AM Juan José Ramos <jr...@pivotal.io> wrote:
>
> > 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 execution, and also provide our users with the
> > means to customize the behaviour on their own desire, meaning that the
> > configurable *Authorizer* stuff is still needed (it's up to them if they
> > want to re-introduce CVE-2017-9795).
> > Either way, this is not my decision to make, it's up to the community to
> > decide. I'll go ahead and update the proposal, we can have another
> feedback
> > round (1 week) and cast votes afterwards.
> > Cheers.
> >
> >
> > On Tue, Jul 2, 2019 at 5:23 PM Jason Huynh <jh...@pivotal.io> wrote:
> >
> > > 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 heavy handed deny all
> method
> > > invocations:
> > >
> > > CVE-2017-9795 Apache Geode OQL method invocation vulnerability
> > >
> > > Description:
> > > A malicious user with read access to specific regions within a Geode
> > > cluster may execute OQL queries that allow read and write access to
> > > objects within unauthorized regions. In addition a user could invoke
> > > methods that allow remote code execution
> > >
> > > I think Juan's proposal would still allow us to provide multiple
> > solutions
> > > that may or may not reopen that hole, but it would be up to the user to
> > > decide what they are willing to accept. The choice for what should be
> > > default would still be up for debate...
> > >
> > >
> > >
> > > On Tue, Jul 2, 2019 at 1:07 PM Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > >
> > > >
> > > >
> > > > > On Jul 2, 2019, at 11:58 AM, Juan José Ramos <jr...@pivotal.io>
> > > 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 authentication and
> > > authorization,
> > > > > adding yet another security framework (and mapping between roles
> and
> > > > > permissions between the two of them) for OQL method invocation
> > security
> > > > > seems overkilling to me. I'd rather spend some time improving the
> > > > > *ResourcePermissionBasedMethodAuthorizer
> > > >
> > > > The security manager doesn’t have to be as fined grained as
> individual
> > > > users. Do we really intend to support actions on objects base on
> > current
> > > > user too?
> > > >
> > > > > [1] *and/or adding *Permissions*/*Roles* to our current security
> > > > framework
> > > > > than introducing a new security framework altogether.
> > > >
> > > > Again, we don’t have to add anything. If the user wants to restrict
> > > access
> > > > to certain activities they could add a policy file to the JVM to do
> so.
> > > It
> > > > doesn’t have to be user based. We could simply have two hard coded
> > roles,
> > > > UserCode and SystemCode. SystemCode has AllPermissions, UserCode has
> > > none.
> > > > Now we run all queries under the context of UserCode and it can’t
> > execute
> > > > any File, Runtime, Socket, etc.
> > > >
> > > > > 2). There can only be one *Security Manager* per JVM at a given
> time
> > > > Eh, sorta but no, you can use thread contexts and class loader
> > isolation,
> > > > but there really doesn’t need to be more than one.
> > > > .
> > > > > 3). Customers already using a custom *Security Manager* on their
> own
> > > will
> > > > > be in trouble... we can certainly wrote our own implementation as a
> > > > > composite and parse multiple policy files, but this will probably
> > break
> > > > the
> > > > > backward compatibility for these customers (and requires yet more
> > > > > configuration and things to keep in mind when upgrading).
> > > > Their custom SecurityManager would conform to the same rules as the
> > > > default file based one in the JRE. They would be able to control code
> > > > access using their existing framework. Seems like win to me.
> > > >
> > > > > 4). The current set of default *Permissions* (*PropertyPermission*,
> > > > > *FilePermission*, etc.) don't apply to our use case, so we'll need
> to
> > > > > create our own implementations and do some plumbing to map to what
> we
> > > > > currently have in terms of principals and roles (more boilerplate).
> > > >
> > > > How do they not apply?
> > > >
> > > > > 5). In order to check a permission we basically need to check
> > whether a
> > > > > Security Manager is installed (*System.getSecurityManager() !=
> null*)
> > > and
> > > > > execute the check afterwards
> > > (*securityManager**.checkPermission(perm)*);
> > > > > the *Security Manager* then looks at the classes of all methods
> > > currently
> > > > > within the call stack (roughly speaking) and returns or throws an
> > > > > exception... a lookup through a simple Map is probably faster, and
> > > easier
> > > > > to maintain and read.
> > > >
> > > > All the things we need to be protected from have already been coded
> > with
> > > > these checks in the JRE. Do you think we need to protect other
> > > activities?
> > > >
> > > > -Jake
> > > >
> > > >
> > >
> >
> >
> > --
> > Juan José Ramos Cassella
> > Senior Technical Support Engineer
> > Email: jramos@pivotal.io
> > Office#: +353 21 4238611
> > Mobile#: +353 87 2074066
> > After Hours Contact#: +1 877 477 2269
> > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > How to upload artifacts:
> > https://support.pivotal.io/hc/en-us/articles/204369073
> > How to escalate a ticket:
> > https://support.pivotal.io/hc/en-us/articles/203809556
> >
> > [image: support] <https://support.pivotal.io/> [image: twitter]
> > <https://twitter.com/pivotal> [image: linkedin]
> > <https://www.linkedin.com/company/3048967> [image: facebook]
> > <https://www.facebook.com/pivotalsoftware> [image: google plus]
> > <https://plus.google.com/+Pivotal> [image: youtube]
> > <
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
> >
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Dan Smith <ds...@pivotal.io>.
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
shooting themselves in the foot?" I think we do need to honor the security
policies that administrators have configured for geode. Since we allow the
administrators to configure the system to give certain users READ but not
WRITE access, it's on us to make sure those users are not allowed to modify
the data. If users with READ access can modify data, that is a security
vulnerability in Geode.
-Dan
On Wed, Jul 3, 2019 at 8:33 AM Juan José Ramos <jr...@pivotal.io> wrote:
> 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 execution, and also provide our users with the
> means to customize the behaviour on their own desire, meaning that the
> configurable *Authorizer* stuff is still needed (it's up to them if they
> want to re-introduce CVE-2017-9795).
> Either way, this is not my decision to make, it's up to the community to
> decide. I'll go ahead and update the proposal, we can have another feedback
> round (1 week) and cast votes afterwards.
> Cheers.
>
>
> On Tue, Jul 2, 2019 at 5:23 PM Jason Huynh <jh...@pivotal.io> wrote:
>
> > 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 heavy handed deny all method
> > invocations:
> >
> > CVE-2017-9795 Apache Geode OQL method invocation vulnerability
> >
> > Description:
> > A malicious user with read access to specific regions within a Geode
> > cluster may execute OQL queries that allow read and write access to
> > objects within unauthorized regions. In addition a user could invoke
> > methods that allow remote code execution
> >
> > I think Juan's proposal would still allow us to provide multiple
> solutions
> > that may or may not reopen that hole, but it would be up to the user to
> > decide what they are willing to accept. The choice for what should be
> > default would still be up for debate...
> >
> >
> >
> > On Tue, Jul 2, 2019 at 1:07 PM Jacob Barrett <jb...@pivotal.io>
> wrote:
> >
> > >
> > >
> > > > On Jul 2, 2019, at 11:58 AM, Juan José Ramos <jr...@pivotal.io>
> > 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 authentication and
> > authorization,
> > > > adding yet another security framework (and mapping between roles and
> > > > permissions between the two of them) for OQL method invocation
> security
> > > > seems overkilling to me. I'd rather spend some time improving the
> > > > *ResourcePermissionBasedMethodAuthorizer
> > >
> > > The security manager doesn’t have to be as fined grained as individual
> > > users. Do we really intend to support actions on objects base on
> current
> > > user too?
> > >
> > > > [1] *and/or adding *Permissions*/*Roles* to our current security
> > > framework
> > > > than introducing a new security framework altogether.
> > >
> > > Again, we don’t have to add anything. If the user wants to restrict
> > access
> > > to certain activities they could add a policy file to the JVM to do so.
> > It
> > > doesn’t have to be user based. We could simply have two hard coded
> roles,
> > > UserCode and SystemCode. SystemCode has AllPermissions, UserCode has
> > none.
> > > Now we run all queries under the context of UserCode and it can’t
> execute
> > > any File, Runtime, Socket, etc.
> > >
> > > > 2). There can only be one *Security Manager* per JVM at a given time
> > > Eh, sorta but no, you can use thread contexts and class loader
> isolation,
> > > but there really doesn’t need to be more than one.
> > > .
> > > > 3). Customers already using a custom *Security Manager* on their own
> > will
> > > > be in trouble... we can certainly wrote our own implementation as a
> > > > composite and parse multiple policy files, but this will probably
> break
> > > the
> > > > backward compatibility for these customers (and requires yet more
> > > > configuration and things to keep in mind when upgrading).
> > > Their custom SecurityManager would conform to the same rules as the
> > > default file based one in the JRE. They would be able to control code
> > > access using their existing framework. Seems like win to me.
> > >
> > > > 4). The current set of default *Permissions* (*PropertyPermission*,
> > > > *FilePermission*, etc.) don't apply to our use case, so we'll need to
> > > > create our own implementations and do some plumbing to map to what we
> > > > currently have in terms of principals and roles (more boilerplate).
> > >
> > > How do they not apply?
> > >
> > > > 5). In order to check a permission we basically need to check
> whether a
> > > > Security Manager is installed (*System.getSecurityManager() != null*)
> > and
> > > > execute the check afterwards
> > (*securityManager**.checkPermission(perm)*);
> > > > the *Security Manager* then looks at the classes of all methods
> > currently
> > > > within the call stack (roughly speaking) and returns or throws an
> > > > exception... a lookup through a simple Map is probably faster, and
> > easier
> > > > to maintain and read.
> > >
> > > All the things we need to be protected from have already been coded
> with
> > > these checks in the JRE. Do you think we need to protect other
> > activities?
> > >
> > > -Jake
> > >
> > >
> >
>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 execution, and also provide our users with the
means to customize the behaviour on their own desire, meaning that the
configurable *Authorizer* stuff is still needed (it's up to them if they
want to re-introduce CVE-2017-9795).
Either way, this is not my decision to make, it's up to the community to
decide. I'll go ahead and update the proposal, we can have another feedback
round (1 week) and cast votes afterwards.
Cheers.
On Tue, Jul 2, 2019 at 5:23 PM Jason Huynh <jh...@pivotal.io> wrote:
> 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 heavy handed deny all method
> invocations:
>
> CVE-2017-9795 Apache Geode OQL method invocation vulnerability
>
> Description:
> A malicious user with read access to specific regions within a Geode
> cluster may execute OQL queries that allow read and write access to
> objects within unauthorized regions. In addition a user could invoke
> methods that allow remote code execution
>
> I think Juan's proposal would still allow us to provide multiple solutions
> that may or may not reopen that hole, but it would be up to the user to
> decide what they are willing to accept. The choice for what should be
> default would still be up for debate...
>
>
>
> On Tue, Jul 2, 2019 at 1:07 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
> >
> >
> > > On Jul 2, 2019, at 11:58 AM, Juan José Ramos <jr...@pivotal.io>
> 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 authentication and
> authorization,
> > > adding yet another security framework (and mapping between roles and
> > > permissions between the two of them) for OQL method invocation security
> > > seems overkilling to me. I'd rather spend some time improving the
> > > *ResourcePermissionBasedMethodAuthorizer
> >
> > The security manager doesn’t have to be as fined grained as individual
> > users. Do we really intend to support actions on objects base on current
> > user too?
> >
> > > [1] *and/or adding *Permissions*/*Roles* to our current security
> > framework
> > > than introducing a new security framework altogether.
> >
> > Again, we don’t have to add anything. If the user wants to restrict
> access
> > to certain activities they could add a policy file to the JVM to do so.
> It
> > doesn’t have to be user based. We could simply have two hard coded roles,
> > UserCode and SystemCode. SystemCode has AllPermissions, UserCode has
> none.
> > Now we run all queries under the context of UserCode and it can’t execute
> > any File, Runtime, Socket, etc.
> >
> > > 2). There can only be one *Security Manager* per JVM at a given time
> > Eh, sorta but no, you can use thread contexts and class loader isolation,
> > but there really doesn’t need to be more than one.
> > .
> > > 3). Customers already using a custom *Security Manager* on their own
> will
> > > be in trouble... we can certainly wrote our own implementation as a
> > > composite and parse multiple policy files, but this will probably break
> > the
> > > backward compatibility for these customers (and requires yet more
> > > configuration and things to keep in mind when upgrading).
> > Their custom SecurityManager would conform to the same rules as the
> > default file based one in the JRE. They would be able to control code
> > access using their existing framework. Seems like win to me.
> >
> > > 4). The current set of default *Permissions* (*PropertyPermission*,
> > > *FilePermission*, etc.) don't apply to our use case, so we'll need to
> > > create our own implementations and do some plumbing to map to what we
> > > currently have in terms of principals and roles (more boilerplate).
> >
> > How do they not apply?
> >
> > > 5). In order to check a permission we basically need to check whether a
> > > Security Manager is installed (*System.getSecurityManager() != null*)
> and
> > > execute the check afterwards
> (*securityManager**.checkPermission(perm)*);
> > > the *Security Manager* then looks at the classes of all methods
> currently
> > > within the call stack (roughly speaking) and returns or throws an
> > > exception... a lookup through a simple Map is probably faster, and
> easier
> > > to maintain and read.
> >
> > All the things we need to be protected from have already been coded with
> > these checks in the JRE. Do you think we need to protect other
> activities?
> >
> > -Jake
> >
> >
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jason Huynh <jh...@pivotal.io>.
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 heavy handed deny all method
invocations:
CVE-2017-9795 Apache Geode OQL method invocation vulnerability
Description:
A malicious user with read access to specific regions within a Geode
cluster may execute OQL queries that allow read and write access to
objects within unauthorized regions. In addition a user could invoke
methods that allow remote code execution
I think Juan's proposal would still allow us to provide multiple solutions
that may or may not reopen that hole, but it would be up to the user to
decide what they are willing to accept. The choice for what should be
default would still be up for debate...
On Tue, Jul 2, 2019 at 1:07 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>
> > On Jul 2, 2019, at 11:58 AM, Juan José Ramos <jr...@pivotal.io> 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 authentication and authorization,
> > adding yet another security framework (and mapping between roles and
> > permissions between the two of them) for OQL method invocation security
> > seems overkilling to me. I'd rather spend some time improving the
> > *ResourcePermissionBasedMethodAuthorizer
>
> The security manager doesn’t have to be as fined grained as individual
> users. Do we really intend to support actions on objects base on current
> user too?
>
> > [1] *and/or adding *Permissions*/*Roles* to our current security
> framework
> > than introducing a new security framework altogether.
>
> Again, we don’t have to add anything. If the user wants to restrict access
> to certain activities they could add a policy file to the JVM to do so. It
> doesn’t have to be user based. We could simply have two hard coded roles,
> UserCode and SystemCode. SystemCode has AllPermissions, UserCode has none.
> Now we run all queries under the context of UserCode and it can’t execute
> any File, Runtime, Socket, etc.
>
> > 2). There can only be one *Security Manager* per JVM at a given time
> Eh, sorta but no, you can use thread contexts and class loader isolation,
> but there really doesn’t need to be more than one.
> .
> > 3). Customers already using a custom *Security Manager* on their own will
> > be in trouble... we can certainly wrote our own implementation as a
> > composite and parse multiple policy files, but this will probably break
> the
> > backward compatibility for these customers (and requires yet more
> > configuration and things to keep in mind when upgrading).
> Their custom SecurityManager would conform to the same rules as the
> default file based one in the JRE. They would be able to control code
> access using their existing framework. Seems like win to me.
>
> > 4). The current set of default *Permissions* (*PropertyPermission*,
> > *FilePermission*, etc.) don't apply to our use case, so we'll need to
> > create our own implementations and do some plumbing to map to what we
> > currently have in terms of principals and roles (more boilerplate).
>
> How do they not apply?
>
> > 5). In order to check a permission we basically need to check whether a
> > Security Manager is installed (*System.getSecurityManager() != null*) and
> > execute the check afterwards (*securityManager**.checkPermission(perm)*);
> > the *Security Manager* then looks at the classes of all methods currently
> > within the call stack (roughly speaking) and returns or throws an
> > exception... a lookup through a simple Map is probably faster, and easier
> > to maintain and read.
>
> All the things we need to be protected from have already been coded with
> these checks in the JRE. Do you think we need to protect other activities?
>
> -Jake
>
>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jacob Barrett <jb...@pivotal.io>.
> On Jul 2, 2019, at 11:58 AM, Juan José Ramos <jr...@pivotal.io> 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 authentication and authorization,
> adding yet another security framework (and mapping between roles and
> permissions between the two of them) for OQL method invocation security
> seems overkilling to me. I'd rather spend some time improving the
> *ResourcePermissionBasedMethodAuthorizer
The security manager doesn’t have to be as fined grained as individual users. Do we really intend to support actions on objects base on current user too?
> [1] *and/or adding *Permissions*/*Roles* to our current security framework
> than introducing a new security framework altogether.
Again, we don’t have to add anything. If the user wants to restrict access to certain activities they could add a policy file to the JVM to do so. It doesn’t have to be user based. We could simply have two hard coded roles, UserCode and SystemCode. SystemCode has AllPermissions, UserCode has none. Now we run all queries under the context of UserCode and it can’t execute any File, Runtime, Socket, etc.
> 2). There can only be one *Security Manager* per JVM at a given time
Eh, sorta but no, you can use thread contexts and class loader isolation, but there really doesn’t need to be more than one.
.
> 3). Customers already using a custom *Security Manager* on their own will
> be in trouble... we can certainly wrote our own implementation as a
> composite and parse multiple policy files, but this will probably break the
> backward compatibility for these customers (and requires yet more
> configuration and things to keep in mind when upgrading).
Their custom SecurityManager would conform to the same rules as the default file based one in the JRE. They would be able to control code access using their existing framework. Seems like win to me.
> 4). The current set of default *Permissions* (*PropertyPermission*,
> *FilePermission*, etc.) don't apply to our use case, so we'll need to
> create our own implementations and do some plumbing to map to what we
> currently have in terms of principals and roles (more boilerplate).
How do they not apply?
> 5). In order to check a permission we basically need to check whether a
> Security Manager is installed (*System.getSecurityManager() != null*) and
> execute the check afterwards (*securityManager**.checkPermission(perm)*);
> the *Security Manager* then looks at the classes of all methods currently
> within the call stack (roughly speaking) and returns or throws an
> exception... a lookup through a simple Map is probably faster, and easier
> to maintain and read.
All the things we need to be protected from have already been coded with these checks in the JRE. Do you think we need to protect other activities?
-Jake
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 mapping between roles and
permissions between the two of them) for OQL method invocation security
seems overkilling to me. I'd rather spend some time improving the
*ResourcePermissionBasedMethodAuthorizer
[1] *and/or adding *Permissions*/*Roles* to our current security framework
than introducing a new security framework altogether.
2). There can only be one *Security Manager* per JVM at a given time.
3). Customers already using a custom *Security Manager* on their own will
be in trouble... we can certainly wrote our own implementation as a
composite and parse multiple policy files, but this will probably break the
backward compatibility for these customers (and requires yet more
configuration and things to keep in mind when upgrading).
4). The current set of default *Permissions* (*PropertyPermission*,
*FilePermission*, etc.) don't apply to our use case, so we'll need to
create our own implementations and do some plumbing to map to what we
currently have in terms of principals and roles (more boilerplate).
5). In order to check a permission we basically need to check whether a
Security Manager is installed (*System.getSecurityManager() != null*) and
execute the check afterwards (*securityManager**.checkPermission(perm)*);
the *Security Manager* then looks at the classes of all methods currently
within the call stack (roughly speaking) and returns or throws an
exception... a lookup through a simple Map is probably faster, and easier
to maintain and read.
6). Overall, it feels like killing mosquitoes with a bazooka to me: it's
certainly a powerful framework and we might certainly use it to achieve our
goal, but it just seems too complicated for what we are trying to do.
My expertise with the *Java Security Manager* has came from what I've
recently read, anyway, so chances are high that I might be missing
something :-).
That said, if we all agree in that *we can't prevent users from shooting
themselves in the foot* (thanks for that phrase!!) then things become
somewhat trivial: we known which internal methods can compromise the
integrity of the system and we also know which general methods are
dangerous, so we just need to have an immutable structure within our
default authorizer and check if the method belongs to it or not to decide
whether it should be allowed/denied. We can certainly provide the other 2
or 3 implementations out of the box and allow customers to provide their
own in case they want to restrict things further but, as far as this
proposal goes, I think we're good to incorporate the comments/suggestions
gathered and go for another feedback round (it's what I plan to do now).
Cheers.
[1]:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-ResourcePermissionBasedMethodAuthorizer
On Mon, Jul 1, 2019 at 12:57 PM Juan José Ramos <jr...@pivotal.io> wrote:
> 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 would need to know under what conditions my authorize method
> going to be called. Is it going to be for every object that is scanned by
> this method? The API suggests this might be the case given that target is
> an Object and not a Class. We can do some profiling in our head an know
> that if we invoke this method for every potential object we scan then
> performance is going to suffer. The regex matcher will destroy the CPU.
> What if my implementation was to use LDAP, ouch! If we define scope to be
> per query this is orders of magnitude better. The API/SPI should probably
> change to reflect this. Maybe target should be the Class? Should the query
> itself be included? Now if the target is a Class, and classes are
> immutable, perhaps now the authorize method could be invoked once for the
> life of the application only when a new Class is touched in our object
> scan. Such scope would require that either the API/SPI define that rules
> are also immutable or that there is some invalidation mechanism to tell the
> system the rules have been mutated. Again, this has API/SPI ramifications
> that all need to be discussed in this proposal.*
> [Juan]: Agreed, I will keep this in mind when modifying the proposal.
>
> *>> How far do we go to prevent the user from shooting themselves in the
> foot?. Here we could change OQL to any support the bean interface and
> disallow all set operations.*
> [Juan]: I'm not sure about this one... how far do we go?, I guess it's a
> decision the community needs to make. I certainly believe that we can't
> prevent everything, but I also think that we can't force our uses to design
> their model in terms of our one-direction decisions. As an example, why
> should I call my accessor only method get*/is* to be able to invoke it on a
> query?, what if the company I work for wants to use the local native tongue
> and the equivalent for *get*/is** instead of using english all together?,
> etc.
>
>
> *>> I want us to consider systems that exist before we spend time
> inventing our own. There is cost in maintain our own solution in
> implementation time and bug squashing. There is also the cost in training
> on our own solution. SecurityManger is discussed in numerous books and
> blogs, our solution would not have that kind of coverage. Let’s think
> really critically there. What are we trying to prevent? Is there a solution
> in the Java echo system that already does what we really need to do? Can we
> use a preexisting solution and avoid the risk of implementing our own?*
> [Juan]: Agreed!.
>
>
> *>> I have spent plenty of time in the guts of SecurityManager in previous
> lives. I think, based on the intended use of this proposal, that Java
> SecurityManager more than meets our needs.*[Juan]: Fair enough, I'll go
> ahead and do some reading about the *Security Manager *on my own, will
> probably ping you once I have enough context to discuss options (or even
> ask you some questions :-)).
>
> One concern I have, however, is regarding *How far do we go to prevent
> the user from shooting themselves in the foot?*. I think this needs to be
> decided by the community, do we have any formal *poll* mechanism or
> something like that?. As a matter of fact, if we decide to prevent OQL
> method invocation only on our own internal/protected classes (and some
> known dangerous things like getClass), the implementation would be waaaay
> easier...
> Cheers.
>
> On Mon, Jul 1, 2019 at 12:07 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>>
>>
>> > On Jul 1, 2019, at 6:55 AM, Juan José Ramos <jr...@pivotal.io> 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 will have significant implications on performance.
>> > My assumption right
>> > now is that there will be some caching performed and will certainly try
>> to
>> > keep the authorizers immutable but, however, no PoC has been done and
>> the
>> > implementations details shown in the proposal are just a draft, so I'm
>> not
>> > in a position to accurately answer these questions. I also read that
>> > *"premature
>> > optimization is the root of all evil", *so I guess we can benchmark the
>> > solution with and without caching, and decide what's better based on
>> some
>> > real data (I certainly see some gains using caching on the
>> > *RegexBasedMethodAuthorizer*, not sure about the
>> > *JavaBeanAccessorBasedMethodAuthorizer*).
>>
>> 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 would need to know under what conditions my authorize method
>> going to be called. Is it going to be for every object that is scanned by
>> this method? The API suggests this might be the case given that target is
>> an Object and not a Class. We can do some profiling in our head an know
>> that if we invoke this method for every potential object we scan then
>> performance is going to suffer. The regex matcher will destroy the CPU.
>> What if my implementation was to use LDAP, ouch! If we define scope to be
>> per query this is orders of magnitude better. The API/SPI should probably
>> change to reflect this. Maybe target should be the Class? Should the query
>> itself be included? Now if the target is a Class, and classes are
>> immutable, perhaps now the authorize method could be invoked once for the
>> life of the application only when a new Class is touched in our object
>> scan. Such scope would require that either the API/SPI define that rules
>> are also immutable or that there is some invalidation mechanism to tell the
>> system the rules have been mutated. Again, this has API/SPI ramifications
>> that all need to be discussed in this proposal.
>>
>> > The second issue is how does this differ, augment are compete with
>> > Java’s built in Security Manager / Policy system. It was designed for a
>> lot
>> > of these same reasons, restricting application access to specific OS
>> level
>> > operations that can be dangerous if executed by malicious code. Why is
>> such
>> > a system not sufficient to handle our concerns in OQL? Beyond creating
>> > sockets, files, threads, forks, etc. what are we intending to prevent
>> the
>> > OQL user executing?*
>> >> Thanks for pointing this out, I guess I should have included these
>> examples
>> >> in the proposal (will certainly do it in the next iteration) as the
>> >> starting point so readers could see what we wanted to prevent when
>> *GEODE-3247
>> >> [2]* was implemented.
>> >> *1. Reflection (This allows the user to do everything)*
>> >> select * from /region r where
>> >>
>> r.getClass().forName('java.lang.Runtime').getDeclaredMethods()[0].invoke()
>>
>> All of the methods on Runtime use the SecurityManager to prevent
>> invocations by unauthorized contexts. If we executed queries with the
>> correct context and a property configure SecurityManager we are protected.
>>
>> > *2. Doing anything with the cache (closing, accessing all regions,
>> etc.)*
>> > select * from /region.getCache().close()
>> > *3. Destroying, adding or invalidating the entire region or specific
>> > elements*
>> > select * from /region.destroyRegion()
>> > select * from /region.invalidate('xyz')
>> > select * from /region.put('xyz','abc’)
>>
>> We could add SecurityManager checks to our protected calls.
>>
>> > *4. Modifying an object in place*
>> > select r.setName('Zaraza') from /region r
>>
>> How far do we go to prevent the user from shooting themselves in the
>> foot? Here we could change OQL to any support the bean interface and
>> disallow all set operations.
>>
>> > I honestly don't know much about the *Java Security Manager *and didn't
>> > consider its usage due to the fact that it was't considered in the first
>> > place when GEODE-3247 was implemented. I'll spend some time looking at
>> it
>> > today, however, and see if it's applicable to our use case. If you (or
>> > anyone reading this) already has enough knowledge about the *Java
>> Security
>> > Manager* and knows whether we can apply it to our scenario, please shout
>> > and let's have a talk :-).
>>
>> I have spent plenty of time in the guts of SecurityManager in previous
>> lives.
>>
>>
>> I want us to consider systems that exist before we spend time inventing
>> our own. There is cost in maintain our own solution in implementation time
>> and bug squashing. There is also the cost in training on our own solution.
>> SecurityManger is discussed in numerous books and blogs, our solution would
>> not have that kind of coverage. Let’s think really critically there. What
>> are we trying to prevent? Is there a solution in the Java echo system that
>> already does what we really need to do? Can we use a preexisting solution
>> and avoid the risk of implementing our own?
>>
>> I think, based on the intended use of this proposal, that Java
>> SecurityManager more than meets our needs.
>>
>> -Jake
>>
>>
>>
>>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 would need to know under what conditions my authorize method
going to be called. Is it going to be for every object that is scanned by
this method? The API suggests this might be the case given that target is
an Object and not a Class. We can do some profiling in our head an know
that if we invoke this method for every potential object we scan then
performance is going to suffer. The regex matcher will destroy the CPU.
What if my implementation was to use LDAP, ouch! If we define scope to be
per query this is orders of magnitude better. The API/SPI should probably
change to reflect this. Maybe target should be the Class? Should the query
itself be included? Now if the target is a Class, and classes are
immutable, perhaps now the authorize method could be invoked once for the
life of the application only when a new Class is touched in our object
scan. Such scope would require that either the API/SPI define that rules
are also immutable or that there is some invalidation mechanism to tell the
system the rules have been mutated. Again, this has API/SPI ramifications
that all need to be discussed in this proposal.*
[Juan]: Agreed, I will keep this in mind when modifying the proposal.
*>> How far do we go to prevent the user from shooting themselves in the
foot?. Here we could change OQL to any support the bean interface and
disallow all set operations.*
[Juan]: I'm not sure about this one... how far do we go?, I guess it's a
decision the community needs to make. I certainly believe that we can't
prevent everything, but I also think that we can't force our uses to design
their model in terms of our one-direction decisions. As an example, why
should I call my accessor only method get*/is* to be able to invoke it on a
query?, what if the company I work for wants to use the local native tongue
and the equivalent for *get*/is** instead of using english all together?,
etc.
*>> I want us to consider systems that exist before we spend time inventing
our own. There is cost in maintain our own solution in implementation time
and bug squashing. There is also the cost in training on our own solution.
SecurityManger is discussed in numerous books and blogs, our solution would
not have that kind of coverage. Let’s think really critically there. What
are we trying to prevent? Is there a solution in the Java echo system that
already does what we really need to do? Can we use a preexisting solution
and avoid the risk of implementing our own?*
[Juan]: Agreed!.
*>> I have spent plenty of time in the guts of SecurityManager in previous
lives. I think, based on the intended use of this proposal, that Java
SecurityManager more than meets our needs.*[Juan]: Fair enough, I'll go
ahead and do some reading about the *Security Manager *on my own, will
probably ping you once I have enough context to discuss options (or even
ask you some questions :-)).
One concern I have, however, is regarding *How far do we go to prevent the
user from shooting themselves in the foot?*. I think this needs to be
decided by the community, do we have any formal *poll* mechanism or
something like that?. As a matter of fact, if we decide to prevent OQL
method invocation only on our own internal/protected classes (and some
known dangerous things like getClass), the implementation would be waaaay
easier...
Cheers.
On Mon, Jul 1, 2019 at 12:07 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>
> > On Jul 1, 2019, at 6:55 AM, Juan José Ramos <jr...@pivotal.io> 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 will have significant implications on performance.
> > My assumption right
> > now is that there will be some caching performed and will certainly try
> to
> > keep the authorizers immutable but, however, no PoC has been done and the
> > implementations details shown in the proposal are just a draft, so I'm
> not
> > in a position to accurately answer these questions. I also read that
> > *"premature
> > optimization is the root of all evil", *so I guess we can benchmark the
> > solution with and without caching, and decide what's better based on some
> > real data (I certainly see some gains using caching on the
> > *RegexBasedMethodAuthorizer*, not sure about the
> > *JavaBeanAccessorBasedMethodAuthorizer*).
>
> 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 would need to know under what conditions my authorize method
> going to be called. Is it going to be for every object that is scanned by
> this method? The API suggests this might be the case given that target is
> an Object and not a Class. We can do some profiling in our head an know
> that if we invoke this method for every potential object we scan then
> performance is going to suffer. The regex matcher will destroy the CPU.
> What if my implementation was to use LDAP, ouch! If we define scope to be
> per query this is orders of magnitude better. The API/SPI should probably
> change to reflect this. Maybe target should be the Class? Should the query
> itself be included? Now if the target is a Class, and classes are
> immutable, perhaps now the authorize method could be invoked once for the
> life of the application only when a new Class is touched in our object
> scan. Such scope would require that either the API/SPI define that rules
> are also immutable or that there is some invalidation mechanism to tell the
> system the rules have been mutated. Again, this has API/SPI ramifications
> that all need to be discussed in this proposal.
>
> > The second issue is how does this differ, augment are compete with
> > Java’s built in Security Manager / Policy system. It was designed for a
> lot
> > of these same reasons, restricting application access to specific OS
> level
> > operations that can be dangerous if executed by malicious code. Why is
> such
> > a system not sufficient to handle our concerns in OQL? Beyond creating
> > sockets, files, threads, forks, etc. what are we intending to prevent the
> > OQL user executing?*
> >> Thanks for pointing this out, I guess I should have included these
> examples
> >> in the proposal (will certainly do it in the next iteration) as the
> >> starting point so readers could see what we wanted to prevent when
> *GEODE-3247
> >> [2]* was implemented.
> >> *1. Reflection (This allows the user to do everything)*
> >> select * from /region r where
> >>
> r.getClass().forName('java.lang.Runtime').getDeclaredMethods()[0].invoke()
>
> All of the methods on Runtime use the SecurityManager to prevent
> invocations by unauthorized contexts. If we executed queries with the
> correct context and a property configure SecurityManager we are protected.
>
> > *2. Doing anything with the cache (closing, accessing all regions, etc.)*
> > select * from /region.getCache().close()
> > *3. Destroying, adding or invalidating the entire region or specific
> > elements*
> > select * from /region.destroyRegion()
> > select * from /region.invalidate('xyz')
> > select * from /region.put('xyz','abc’)
>
> We could add SecurityManager checks to our protected calls.
>
> > *4. Modifying an object in place*
> > select r.setName('Zaraza') from /region r
>
> How far do we go to prevent the user from shooting themselves in the foot?
> Here we could change OQL to any support the bean interface and disallow all
> set operations.
>
> > I honestly don't know much about the *Java Security Manager *and didn't
> > consider its usage due to the fact that it was't considered in the first
> > place when GEODE-3247 was implemented. I'll spend some time looking at it
> > today, however, and see if it's applicable to our use case. If you (or
> > anyone reading this) already has enough knowledge about the *Java
> Security
> > Manager* and knows whether we can apply it to our scenario, please shout
> > and let's have a talk :-).
>
> I have spent plenty of time in the guts of SecurityManager in previous
> lives.
>
>
> I want us to consider systems that exist before we spend time inventing
> our own. There is cost in maintain our own solution in implementation time
> and bug squashing. There is also the cost in training on our own solution.
> SecurityManger is discussed in numerous books and blogs, our solution would
> not have that kind of coverage. Let’s think really critically there. What
> are we trying to prevent? Is there a solution in the Java echo system that
> already does what we really need to do? Can we use a preexisting solution
> and avoid the risk of implementing our own?
>
> I think, based on the intended use of this proposal, that Java
> SecurityManager more than meets our needs.
>
> -Jake
>
>
>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jacob Barrett <jb...@pivotal.io>.
> On Jul 1, 2019, at 6:55 AM, Juan José Ramos <jr...@pivotal.io> 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 will have significant implications on performance.
> My assumption right
> now is that there will be some caching performed and will certainly try to
> keep the authorizers immutable but, however, no PoC has been done and the
> implementations details shown in the proposal are just a draft, so I'm not
> in a position to accurately answer these questions. I also read that
> *"premature
> optimization is the root of all evil", *so I guess we can benchmark the
> solution with and without caching, and decide what's better based on some
> real data (I certainly see some gains using caching on the
> *RegexBasedMethodAuthorizer*, not sure about the
> *JavaBeanAccessorBasedMethodAuthorizer*).
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 would need to know under what conditions my authorize method going to be called. Is it going to be for every object that is scanned by this method? The API suggests this might be the case given that target is an Object and not a Class. We can do some profiling in our head an know that if we invoke this method for every potential object we scan then performance is going to suffer. The regex matcher will destroy the CPU. What if my implementation was to use LDAP, ouch! If we define scope to be per query this is orders of magnitude better. The API/SPI should probably change to reflect this. Maybe target should be the Class? Should the query itself be included? Now if the target is a Class, and classes are immutable, perhaps now the authorize method could be invoked once for the life of the application only when a new Class is touched in our object scan. Such scope would require that either the API/SPI define that rules are also immutable or that there is some invalidation mechanism to tell the system the rules have been mutated. Again, this has API/SPI ramifications that all need to be discussed in this proposal.
> The second issue is how does this differ, augment are compete with
> Java’s built in Security Manager / Policy system. It was designed for a lot
> of these same reasons, restricting application access to specific OS level
> operations that can be dangerous if executed by malicious code. Why is such
> a system not sufficient to handle our concerns in OQL? Beyond creating
> sockets, files, threads, forks, etc. what are we intending to prevent the
> OQL user executing?*
>> Thanks for pointing this out, I guess I should have included these examples
>> in the proposal (will certainly do it in the next iteration) as the
>> starting point so readers could see what we wanted to prevent when *GEODE-3247
>> [2]* was implemented.
>> *1. Reflection (This allows the user to do everything)*
>> select * from /region r where
>> r.getClass().forName('java.lang.Runtime').getDeclaredMethods()[0].invoke()
All of the methods on Runtime use the SecurityManager to prevent invocations by unauthorized contexts. If we executed queries with the correct context and a property configure SecurityManager we are protected.
> *2. Doing anything with the cache (closing, accessing all regions, etc.)*
> select * from /region.getCache().close()
> *3. Destroying, adding or invalidating the entire region or specific
> elements*
> select * from /region.destroyRegion()
> select * from /region.invalidate('xyz')
> select * from /region.put('xyz','abc’)
We could add SecurityManager checks to our protected calls.
> *4. Modifying an object in place*
> select r.setName('Zaraza') from /region r
How far do we go to prevent the user from shooting themselves in the foot? Here we could change OQL to any support the bean interface and disallow all set operations.
> I honestly don't know much about the *Java Security Manager *and didn't
> consider its usage due to the fact that it was't considered in the first
> place when GEODE-3247 was implemented. I'll spend some time looking at it
> today, however, and see if it's applicable to our use case. If you (or
> anyone reading this) already has enough knowledge about the *Java Security
> Manager* and knows whether we can apply it to our scenario, please shout
> and let's have a talk :-).
I have spent plenty of time in the guts of SecurityManager in previous lives.
I want us to consider systems that exist before we spend time inventing our own. There is cost in maintain our own solution in implementation time and bug squashing. There is also the cost in training on our own solution. SecurityManger is discussed in numerous books and blogs, our solution would not have that kind of coverage. Let’s think really critically there. What are we trying to prevent? Is there a solution in the Java echo system that already does what we really need to do? Can we use a preexisting solution and avoid the risk of implementing our own?
I think, based on the intended use of this proposal, that Java SecurityManager more than meets our needs.
-Jake
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 answer them today on the WIKI directly.
Either way, now that the *Lightweight RFC Process [1]* has been released,
I'll go ahead and address all comments here in the email thread.
*>> 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 will have significant implications on performance.*My assumption right
now is that there will be some caching performed and will certainly try to
keep the authorizers immutable but, however, no PoC has been done and the
implementations details shown in the proposal are just a draft, so I'm not
in a position to accurately answer these questions. I also read that
*"premature
optimization is the root of all evil", *so I guess we can benchmark the
solution with and without caching, and decide what's better based on some
real data (I certainly see some gains using caching on the
*RegexBasedMethodAuthorizer*, not sure about the
*JavaBeanAccessorBasedMethodAuthorizer*).
*>> The second issue is how does this differ, augment are compete with
Java’s built in Security Manager / Policy system. It was designed for a lot
of these same reasons, restricting application access to specific OS level
operations that can be dangerous if executed by malicious code. Why is such
a system not sufficient to handle our concerns in OQL? Beyond creating
sockets, files, threads, forks, etc. what are we intending to prevent the
OQL user executing?*
Thanks for pointing this out, I guess I should have included these examples
in the proposal (will certainly do it in the next iteration) as the
starting point so readers could see what we wanted to prevent when *GEODE-3247
[2]* was implemented.
*1. Reflection (This allows the user to do everything)*
select * from /region r where
r.getClass().forName('java.lang.Runtime').getDeclaredMethods()[0].invoke()
*2. Doing anything with the cache (closing, accessing all regions, etc.)*
select * from /region.getCache().close()
*3. Destroying, adding or invalidating the entire region or specific
elements*
select * from /region.destroyRegion()
select * from /region.invalidate('xyz')
select * from /region.put('xyz','abc')
*4. Modifying an object in place*
select r.setName('Zaraza') from /region r
I think the authorizers from the proposal covers items 1, 2 and 3; item 4
is more complicated and I currently don't see a way to prevent in place
modifications (other than trusting that accessor methods - get/is - don't
modify the object or denying everything but let users customize exactly
what should be allowed through regex).
I honestly don't know much about the *Java Security Manager *and didn't
consider its usage due to the fact that it was't considered in the first
place when GEODE-3247 was implemented. I'll spend some time looking at it
today, however, and see if it's applicable to our use case. If you (or
anyone reading this) already has enough knowledge about the *Java Security
Manager* and knows whether we can apply it to our scenario, please shout
and let's have a talk :-).
Best regards.
[1]:
https://cwiki.apache.org/confluence/display/GEODE/Lightweight+RFC+Process
[2]: https://issues.apache.org/jira/browse/GEODE-3247
On Fri, Jun 28, 2019 at 6:29 PM Jacob Barrett <jb...@pivotal.io> wrote:
> 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
> 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 will have significant implications on performance.
>
> The second issue is how does this differ, augment are compete with Java’s
> built in Security Manager / Policy system. It was designed for a lot of
> these same reasons, restricting application access to specific OS level
> operations that can be dangerous if executed by malicious code. Why is such
> a system not sufficient to handle our concerns in OQL? Beyond creating
> sockets, files, threads, forks, etc. what are we intending to prevent the
> OQL user executing?
>
> Thanks,
> Jake
>
>
> > On Jun 28, 2019, at 10:36 AM, Juan José Ramos <jr...@pivotal.io> wrote:
> >
> > 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.
> >
>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jacob Barrett <jb...@pivotal.io>.
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 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 will have significant implications on performance.
The second issue is how does this differ, augment are compete with Java’s built in Security Manager / Policy system. It was designed for a lot of these same reasons, restricting application access to specific OS level operations that can be dangerous if executed by malicious code. Why is such a system not sufficient to handle our concerns in OQL? Beyond creating sockets, files, threads, forks, etc. what are we intending to prevent the OQL user executing?
Thanks,
Jake
> On Jun 28, 2019, at 10:36 AM, Juan José Ramos <jr...@pivotal.io> wrote:
>
> 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.
>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 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 actually a JavaBean accessor method.
However, I can also see how nice this would be in terms of ease-of-use.
[JUAN]: Agreed, it is actually one of the Risks / Unknowns / Disadvantages
[1] pointed out in the proposal.
[Aaron]: From a security standpoint I prefer
AnnotationBasedMethodAuthorizer because it's very explicit on which methods
may be executed. To remove the coupling between the configuration and
domain classes, you could separate out the mapping of which methods are
allowed into a different class and not use annotations.
[JUAN]: Sure, but that separation implies something even worse if you ask
me: we would be forcing our customers to modify their domain model in order
to use our product.
[Aaron]: How have other projects solved this problem? Can we add a "related
work" section to the proposal? If you've already looked and didn't really
find anything relevant you could also mention that in the proposal.
[JUAN]: 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 execute them. The `AnnotationBasedMethodAuthorizer` approach is
somewhat similar to that.
[Anthony]: I shouldn’t have to change my domain classes in order to run a
query.
[JUAN]: Fully agreed, and this is one of the reasons why the
`AnnotationBasedMethodAuthorizer` won't be provided out of the box. If
users would like to follow this approach, they can certainly provide an
implementation similar to one shown in the proposal and annotate the
methods on their domain model.
[Anthony]: I shouldn’t have to configure anything to run a “normal” query
that uses classes deployed into the cluster and stored in the region.
[JUAN]: I'd say I agree with this one, though I haven't found a feasible
way to implement it yet. The actual Region is not always available within
the query tree, specially when invoking chained methods. Going up through
the object hierarchy to find out whether the root object is part of the
Region would also be very poor in terms of performance, especially through
the usage of java reflection. Also, what about methods that actually mutate
the object?.
[Anthony]: By default the cluster is secure from malicious users trying to
execute untrusted code. If a user chooses to deploy code into the cluster
that does bad things that’s on them.
[JUAN]: Agreed but, again, what about methods that actually mutate the
object?.
[Dan]: 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 that modify the data or not.
[JUAN]: Agreed. I might need to investigate some more, but I don't see a
way of preventing users from modifying the objects if they invoke a mutator
method, anyway. Even if we restrict method invocation to getters
(`JavaBeanAccessorBasedMethodAuthorizer`), users can actually do whatever
they want within a get*/is* method, even modify the object itself...
executing a deep copy of the object and execute the method on that copy
instead of the actual reference might be doable, but do we really want to
go down this path?, it would be a nightmare performance wise.
[Dan]: OQL lets you invoke methods on objects that are passed as parameters
to the query. So that means that any class that exists on the server and is
serializable could potentially have methods invoked in it through a query
when someone opens up access with one of these MethodInvocationAuthorizers.
So the RegexBasedMethodAuthorizer needs to be used with care.
[JUAN]: Agreed and, adding to the your first point as well, this approach
both the most powerful and most dangerous one: users can accidentally allow
untrusted methods by making a mistake on the RegEx, but they can also be
sure to permit only safe methods as they are the only ones that actually
know what each method from the domain model is doing.
--------------------------------------------------------
At this point I believe the major concern regarding the proposal is that
there's no out of the box implementation that allows users to get up and
running without needing to manually configure something extra (I'm also
reading that this implementation should be the one used by default when
security is enabled). I certainly understand that we want to make things
easy for our users and, in the end, it will always be their responsibility
to make that sure the cluster is secured, that the deployed code is "safe",
and that their internal users and operators are correctly trained to use
the product.
With that in mind, would it be correct to assume that the following (draft)
MethodAuthorizer addresses these concerns (the other two out of box
implementations will still be available to the users)?:
*[MeaningfulPrefix?]MethodAuthorizer*
Allow any method execution as long as the target object *does not belong to
Geode packages, or does belong but it's marked as safe*. Some known
dangerous methods (like getClass) will be rejected, no matter whether the
target object belongs to a Geode package or not. The implementation will
have an internal list of "safe" Geode methods, and use that to decide
whether a method invoked on a Geode class is allowed or denied.
The pseudocode:
- If the target object doesn't belong to a Geode package, allow its
execution.
- If the target object belongs to a Geode package:
. Is it marked as safe?, allow its execution.
. It is not marked as safe?, deny its execution.
*Advantages*
. Easy to implement.
. Easy to use, no extra configuration needed.
. Solves the general use case: deploy the domain model, start executing OQL
and invoking methods without further changes.
*Risks / Unknowns / Disadvantages*
. All methods will be allowed, including those that actually mutate objects.
. Methods on OQL bind parameters will be allowed as well, and that
basically can be anything.
Whatever we do and no matter which approach we follow, we'll end up
invoking alien methods anyway and we certainly can't prevent these methods
from modifying the objects in memory, at the end of the day it will the
user's responsibility to ensure operators are correctly trained and no
dangerous objects as used as part of the OQL bind parameters.
Sorry for the long email, I'll wait until Monday to add this new authorizer
as the default out of the box implementation to the proposal, give people
some time to analyze the changes, and will try to schedule a live session
afterwards.
Best regards.
[1]:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-Risks/Unknowns/Disadvantages.1
[2]:
https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
On Wed, Jun 26, 2019 at 2:46 PM Juan José Ramos <jr...@pivotal.io> wrote:
> 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 <ds...@pivotal.io> wrote:
>
>> 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 that modify the data or
>> not.
>> 2) OQL lets you invoke methods on objects that are passed as parameters to
>> the query. So that means that any class that exists on the server and is
>> serializable could potentially have methods invoked in it through a query
>> when someone opens up access with one of these
>> MethodInvocationAuthorizers.
>> So the RegexBasedMethodAuthorizer needs to be used with care.
>>
>> -Dan
>>
>> On Tue, Jun 25, 2019 at 11:53 AM Anthony Baker <ab...@pivotal.io> wrote:
>>
>> > 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 malicious users trying to
>> execute
>> > untrusted code*.
>> >
>> >
>> > Anthony
>> >
>> > * if a user chooses to deploy code into the cluster that does bad things
>> > that’s on them
>> >
>> >
>> > > On Jun 25, 2019, at 11:07 AM, Aaron Lindsey <al...@pivotal.io>
>> wrote:
>> > >
>> > > +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 actually a JavaBean accessor method.
>> > However,
>> > > I can also see how nice this would be in terms of ease-of-use.
>> > > - From a security standpoint I prefer
>> AnnotationBasedMethodAuthorizer
>> > > because it's very explicit on which methods may be executed. To
>> remove
>> > the
>> > > coupling between the configuration and domain classes, you could
>> > separate
>> > > out the mapping of which methods are allowed into a different class
>> > and not
>> > > use annotations.
>> > > - How have other projects solved this problem? Can we add a "related
>> > > work" section to the proposal? If you've already looked and didn't
>> > really
>> > > find anything relevant you could also mention that in the proposal.
>> > >
>> > > - Aaron
>> > >
>> > >
>> > > On Mon, Jun 24, 2019 at 4:31 PM Jason Huynh <jh...@pivotal.io>
>> wrote:
>> > >
>> > >> +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 <ds...@pivotal.io> wrote:
>> > >>
>> > >>> +1
>> > >>>
>> > >>> This proposal looks good to me!
>> > >>>
>> > >>> On Mon, Jun 24, 2019 at 4:15 PM Udo Kohlmeyer <ud...@apache.org>
>> 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 regards.
>> > >>>>>
>> > >>>>> On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett <
>> jbarrett@pivotal.io>
>> > >>>> wrote:
>> > >>>>>
>> > >>>>>>
>> > >>>>>>> On Jun 24, 2019, at 11:49 AM, Juan José Ramos <
>> jramos@pivotal.io>
>> > >>>> 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 session on some medium, like
>> > >> Zoom,
>> > >>>>>> where you can walk through the proposal and take like feedback
>> and
>> > >>>>>> questions?
>> > >>>>>>
>> > >>>>>> Thanks,
>> > >>>>>> Jake
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>
>> > >>>
>> > >>
>> >
>> >
>>
>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 <ds...@pivotal.io> wrote:
> 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 that modify the data or
> not.
> 2) OQL lets you invoke methods on objects that are passed as parameters to
> the query. So that means that any class that exists on the server and is
> serializable could potentially have methods invoked in it through a query
> when someone opens up access with one of these MethodInvocationAuthorizers.
> So the RegexBasedMethodAuthorizer needs to be used with care.
>
> -Dan
>
> On Tue, Jun 25, 2019 at 11:53 AM Anthony Baker <ab...@pivotal.io> wrote:
>
> > 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 malicious users trying to
> execute
> > untrusted code*.
> >
> >
> > Anthony
> >
> > * if a user chooses to deploy code into the cluster that does bad things
> > that’s on them
> >
> >
> > > On Jun 25, 2019, at 11:07 AM, Aaron Lindsey <al...@pivotal.io>
> wrote:
> > >
> > > +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 actually a JavaBean accessor method.
> > However,
> > > I can also see how nice this would be in terms of ease-of-use.
> > > - From a security standpoint I prefer AnnotationBasedMethodAuthorizer
> > > because it's very explicit on which methods may be executed. To
> remove
> > the
> > > coupling between the configuration and domain classes, you could
> > separate
> > > out the mapping of which methods are allowed into a different class
> > and not
> > > use annotations.
> > > - How have other projects solved this problem? Can we add a "related
> > > work" section to the proposal? If you've already looked and didn't
> > really
> > > find anything relevant you could also mention that in the proposal.
> > >
> > > - Aaron
> > >
> > >
> > > On Mon, Jun 24, 2019 at 4:31 PM Jason Huynh <jh...@pivotal.io> wrote:
> > >
> > >> +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 <ds...@pivotal.io> wrote:
> > >>
> > >>> +1
> > >>>
> > >>> This proposal looks good to me!
> > >>>
> > >>> On Mon, Jun 24, 2019 at 4:15 PM Udo Kohlmeyer <ud...@apache.org>
> 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 regards.
> > >>>>>
> > >>>>> On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett <jbarrett@pivotal.io
> >
> > >>>> wrote:
> > >>>>>
> > >>>>>>
> > >>>>>>> On Jun 24, 2019, at 11:49 AM, Juan José Ramos <jramos@pivotal.io
> >
> > >>>> 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 session on some medium, like
> > >> Zoom,
> > >>>>>> where you can walk through the proposal and take like feedback and
> > >>>>>> questions?
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Jake
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Dan Smith <ds...@pivotal.io>.
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 that modify the data or
not.
2) OQL lets you invoke methods on objects that are passed as parameters to
the query. So that means that any class that exists on the server and is
serializable could potentially have methods invoked in it through a query
when someone opens up access with one of these MethodInvocationAuthorizers.
So the RegexBasedMethodAuthorizer needs to be used with care.
-Dan
On Tue, Jun 25, 2019 at 11:53 AM Anthony Baker <ab...@pivotal.io> wrote:
> 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 malicious users trying to execute
> untrusted code*.
>
>
> Anthony
>
> * if a user chooses to deploy code into the cluster that does bad things
> that’s on them
>
>
> > On Jun 25, 2019, at 11:07 AM, Aaron Lindsey <al...@pivotal.io> wrote:
> >
> > +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 actually a JavaBean accessor method.
> However,
> > I can also see how nice this would be in terms of ease-of-use.
> > - From a security standpoint I prefer AnnotationBasedMethodAuthorizer
> > because it's very explicit on which methods may be executed. To remove
> the
> > coupling between the configuration and domain classes, you could
> separate
> > out the mapping of which methods are allowed into a different class
> and not
> > use annotations.
> > - How have other projects solved this problem? Can we add a "related
> > work" section to the proposal? If you've already looked and didn't
> really
> > find anything relevant you could also mention that in the proposal.
> >
> > - Aaron
> >
> >
> > On Mon, Jun 24, 2019 at 4:31 PM Jason Huynh <jh...@pivotal.io> wrote:
> >
> >> +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 <ds...@pivotal.io> wrote:
> >>
> >>> +1
> >>>
> >>> This proposal looks good to me!
> >>>
> >>> On Mon, Jun 24, 2019 at 4:15 PM Udo Kohlmeyer <ud...@apache.org> 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 regards.
> >>>>>
> >>>>> On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett <jb...@pivotal.io>
> >>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>> On Jun 24, 2019, at 11:49 AM, Juan José Ramos <jr...@pivotal.io>
> >>>> 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 session on some medium, like
> >> Zoom,
> >>>>>> where you can walk through the proposal and take like feedback and
> >>>>>> questions?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Jake
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>
>
>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Anthony Baker <ab...@pivotal.io>.
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 malicious users trying to execute untrusted code*.
Anthony
* if a user chooses to deploy code into the cluster that does bad things that’s on them
> On Jun 25, 2019, at 11:07 AM, Aaron Lindsey <al...@pivotal.io> wrote:
>
> +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 actually a JavaBean accessor method. However,
> I can also see how nice this would be in terms of ease-of-use.
> - From a security standpoint I prefer AnnotationBasedMethodAuthorizer
> because it's very explicit on which methods may be executed. To remove the
> coupling between the configuration and domain classes, you could separate
> out the mapping of which methods are allowed into a different class and not
> use annotations.
> - How have other projects solved this problem? Can we add a "related
> work" section to the proposal? If you've already looked and didn't really
> find anything relevant you could also mention that in the proposal.
>
> - Aaron
>
>
> On Mon, Jun 24, 2019 at 4:31 PM Jason Huynh <jh...@pivotal.io> wrote:
>
>> +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 <ds...@pivotal.io> wrote:
>>
>>> +1
>>>
>>> This proposal looks good to me!
>>>
>>> On Mon, Jun 24, 2019 at 4:15 PM Udo Kohlmeyer <ud...@apache.org> 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 regards.
>>>>>
>>>>> On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett <jb...@pivotal.io>
>>>> wrote:
>>>>>
>>>>>>
>>>>>>> On Jun 24, 2019, at 11:49 AM, Juan José Ramos <jr...@pivotal.io>
>>>> 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 session on some medium, like
>> Zoom,
>>>>>> where you can walk through the proposal and take like feedback and
>>>>>> questions?
>>>>>>
>>>>>> Thanks,
>>>>>> Jake
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Aaron Lindsey <al...@pivotal.io>.
+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 actually a JavaBean accessor method. However,
I can also see how nice this would be in terms of ease-of-use.
- From a security standpoint I prefer AnnotationBasedMethodAuthorizer
because it's very explicit on which methods may be executed. To remove the
coupling between the configuration and domain classes, you could separate
out the mapping of which methods are allowed into a different class and not
use annotations.
- How have other projects solved this problem? Can we add a "related
work" section to the proposal? If you've already looked and didn't really
find anything relevant you could also mention that in the proposal.
- Aaron
On Mon, Jun 24, 2019 at 4:31 PM Jason Huynh <jh...@pivotal.io> wrote:
> +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 <ds...@pivotal.io> wrote:
>
> > +1
> >
> > This proposal looks good to me!
> >
> > On Mon, Jun 24, 2019 at 4:15 PM Udo Kohlmeyer <ud...@apache.org> 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 regards.
> > > >
> > > > On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett <jb...@pivotal.io>
> > > wrote:
> > > >
> > > >>
> > > >>> On Jun 24, 2019, at 11:49 AM, Juan José Ramos <jr...@pivotal.io>
> > > 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 session on some medium, like
> Zoom,
> > > >> where you can walk through the proposal and take like feedback and
> > > >> questions?
> > > >>
> > > >> Thanks,
> > > >> Jake
> > > >>
> > > >>
> > > >>
> > >
> >
>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jason Huynh <jh...@pivotal.io>.
+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 <ds...@pivotal.io> wrote:
> +1
>
> This proposal looks good to me!
>
> On Mon, Jun 24, 2019 at 4:15 PM Udo Kohlmeyer <ud...@apache.org> 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 regards.
> > >
> > > On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > >
> > >>
> > >>> On Jun 24, 2019, at 11:49 AM, Juan José Ramos <jr...@pivotal.io>
> > 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 session on some medium, like Zoom,
> > >> where you can walk through the proposal and take like feedback and
> > >> questions?
> > >>
> > >> Thanks,
> > >> Jake
> > >>
> > >>
> > >>
> >
>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Dan Smith <ds...@pivotal.io>.
+1
This proposal looks good to me!
On Mon, Jun 24, 2019 at 4:15 PM Udo Kohlmeyer <ud...@apache.org> 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 regards.
> >
> > On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett <jb...@pivotal.io>
> wrote:
> >
> >>
> >>> On Jun 24, 2019, at 11:49 AM, Juan José Ramos <jr...@pivotal.io>
> 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 session on some medium, like Zoom,
> >> where you can walk through the proposal and take like feedback and
> >> questions?
> >>
> >> Thanks,
> >> Jake
> >>
> >>
> >>
>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Udo Kohlmeyer <ud...@apache.org>.
+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 <jb...@pivotal.io> wrote:
>
>>
>>> On Jun 24, 2019, at 11:49 AM, Juan José Ramos <jr...@pivotal.io> 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 session on some medium, like Zoom,
>> where you can walk through the proposal and take like feedback and
>> questions?
>>
>> Thanks,
>> Jake
>>
>>
>>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 <jb...@pivotal.io> wrote:
>
>
> > On Jun 24, 2019, at 11:49 AM, Juan José Ramos <jr...@pivotal.io> 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 session on some medium, like Zoom,
> where you can walk through the proposal and take like feedback and
> questions?
>
> Thanks,
> Jake
>
>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jacob Barrett <jb...@pivotal.io>.
> On Jun 24, 2019, at 11:49 AM, Juan José Ramos <jr...@pivotal.io> 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 session on some medium, like Zoom, where you can walk through the proposal and take like feedback and questions?
Thanks,
Jake
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 on a standard yet. 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.
Cheers.
On Mon, Jun 24, 2019 at 3:40 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
> > On Jun 24, 2019, at 11:35 AM, Juan José Ramos <jr...@pivotal.io> 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 other. Author’s
> pick since we haven’t settled on a standard. See conversation about RFC-0
> https://github.com/apache/geode/pull/3706 <
> https://github.com/apache/geode/pull/3706>.
>
>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jacob Barrett <jb...@pivotal.io>.
> On Jun 24, 2019, at 11:35 AM, Juan José Ramos <jr...@pivotal.io> 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 other. Author’s pick since we haven’t settled on a standard. See conversation about RFC-0 https://github.com/apache/geode/pull/3706 <https://github.com/apache/geode/pull/3706>.
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 an update regarding the status
of requested changes (if any), or asking a final time for feedback before
considering the proposal approved.
Best regards.
[1]:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
On Fri, Jun 21, 2019 at 2:19 PM Juan José Ramos <jr...@pivotal.io> wrote:
> 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 *here
> [2]. *The former just kicks in whenever a method is executed on the
> region itself (like *getValues*, *keySet*, etc.).
>
> (2). Agreed, another oversight on my side, mostly derived from my
> misunderstanding in item 1.
>
> 3). I'm not sure about how this is going to work either, neither if it's
> even possible without hugely impacting the performance... truth be told,
> the whole idea of this particular authorizer is to allow users to get up
> and running *without configuring anything, *but I'm not sure how it can
> be done in the real world (specially now that you made me aware my error on
> item 1). I'd actually love to just eliminate this authorizer altogether but
> it was brought to my attention that the other two proposed out of box
> implementations require the user to actually configure something (the
> package or the regex expression), and that we should provide some sort of
> automatic trust boundary in the sense that users just deploy the domain
> model, insert objects into the region, and can execute OQL invoking methods
> as long as those methods belong to the objects stored within the region...
> determining whether an object belongs to a region or not is fairly
> complicated, not achievable right now and will certainly incur into
> performance degradation, but I guess is up to the community to decide
> whether we should pursue this objective or not.
>
> As a summary, and before I go ahead and incorporate all the feedback
> provided and modify the proposal, I guess the community needs to answer the
> following questions:
> A. For the sake of security, is it okay to force our users to do some
> extra configuration steps (no matter how little or easy they might be)
> whenever they deploy the domain model to the cluster and want to execute
> some methods on those objects from OQL?.
> B. Should we just change the approach from *deny everything* to *allow
> everything *instead, and assume that users with enough privileges to
> execute queries on the region (*DATA:READ:RegionName*) are trustworthy
> (at the end of the day *somebody* gave them that role) and won't
> compromise the security through RCE from OQL?.
>
> If nothing changes during the weekend, I'll wait until Monday and apply
> the suggested changes to the proposal in favour of a "YES" to question "A"
> (just because that's my preference at the moment), sending a new email
> afterward for another feedback round. Changes will still be accepted anyway
> as this is just the proposal and the community as whole should deny/accept
> it.
> Cheers.
>
> [1]:
> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/RestrictedMethodInvocationAuthorizer.java#L165-L171
> [2]:
> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/BaseCommandQuery.java#L106-L108
>
>
> On Thu, Jun 20, 2019 at 7:22 PM Dan Smith <ds...@pivotal.io> wrote:
>
>> +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 to that?
>> 2. I'm a little unclear on if your
>> MethodInvocationAuthorizer.authorizeMethodInvocation is supposed to take a
>> region or the target object. If it is really accepting a region, do we
>> actually have a region available in all cases? We could be invoking
>> methods
>> on an object in lots of places in the query tree.
>> 3. The DataAwareBasedMethodAuthorizer seems a bit vague on how it's
>> actually going to work. It also might be a security risk, since it will
>> allow users with DATA:READ permission to invoke any method on these
>> objects.
>>
>> -Dan
>>
>> On Wed, Jun 19, 2019 at 11:34 AM Jacob Barrett <jb...@pivotal.io>
>> wrote:
>>
>> > Thanks Juan!
>> >
>> > > On Jun 19, 2019, at 9:55 AM, Juan José Ramos <jr...@pivotal.io>
>> 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.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
>> > >
>> > >> On Fri, Jun 14, 2019 at 8:39 PM Juan José Ramos <jr...@pivotal.io>
>> > wrote:
>> > >>
>> > >> 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
>> if
>> > >> anyone got offended in any way.
>> > >> That said, I won't have time to go through the proposal and make the
>> > >> required changes until next week, so I'll keep the document hidden
>> until
>> > >> all biased words are replaced.
>> > >> Cheers.
>> > >>
>> > >>
>> > >> On Sat, Jun 15, 2019 at 12:25 AM Jacob Barrett <jb...@pivotal.io>
>> > >> wrote:
>> > >>
>> > >>>> As part of GEODE-3247 <
>> > https://issues.apache.org/jira/browse/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
>> > not, the
>> > >>> decision was made to tighten up the Security and, by default,
>> disallow
>> > any
>> > >>> method call not explicitly whitelisted.
>> > >>>
>> > >>> Please avoid biased words, like whitelist, in source and proposals.
>> > There
>> > >>> are several other places in this document that use these terms. Can
>> you
>> > >>> please update the document without them.
>> > >>>
>> > >>> Thanks,
>> > >>> Jake
>> > >>>
>> > >>>
>> > >>
>> > >> --
>> > >> Juan José Ramos Cassella
>> > >> Senior Technical Support Engineer
>> > >> Email: jramos@pivotal.io
>> > >> Office#: +353 21 4238611
>> > >> Mobile#: +353 87 2074066
>> > >> After Hours Contact#: +1 877 477 2269
>> > >> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
>> > >> How to upload artifacts:
>> > >> https://support.pivotal.io/hc/en-us/articles/204369073
>> > >> How to escalate a ticket:
>> > >> https://support.pivotal.io/hc/en-us/articles/203809556
>> > >>
>> > >> [image: support] <https://support.pivotal.io/> [image: twitter]
>> > >> <https://twitter.com/pivotal> [image: linkedin]
>> > >> <https://www.linkedin.com/company/3048967> [image: facebook]
>> > >> <https://www.facebook.com/pivotalsoftware> [image: google plus]
>> > >> <https://plus.google.com/+Pivotal> [image: youtube]
>> > >> <
>> >
>> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>> > >>
>> > >
>> > >
>> > > --
>> > > Juan José Ramos Cassella
>> > > Senior Technical Support Engineer
>> > > Email: jramos@pivotal.io
>> > > Office#: +353 21 4238611
>> > > Mobile#: +353 87 2074066
>> > > After Hours Contact#: +1 877 477 2269
>> > > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
>> > > How to upload artifacts:
>> > > https://support.pivotal.io/hc/en-us/articles/204369073
>> > > How to escalate a ticket:
>> > > https://support.pivotal.io/hc/en-us/articles/203809556
>> > >
>> > > [image: support] <https://support.pivotal.io/> [image: twitter]
>> > > <https://twitter.com/pivotal> [image: linkedin]
>> > > <https://www.linkedin.com/company/3048967> [image: facebook]
>> > > <https://www.facebook.com/pivotalsoftware> [image: google plus]
>> > > <https://plus.google.com/+Pivotal> [image: youtube]
>> > > <
>> >
>> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>> >
>>
>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 *here
[2]. *The former just kicks in whenever a method is executed on the region
itself (like *getValues*, *keySet*, etc.).
(2). Agreed, another oversight on my side, mostly derived from my
misunderstanding in item 1.
3). I'm not sure about how this is going to work either, neither if it's
even possible without hugely impacting the performance... truth be told,
the whole idea of this particular authorizer is to allow users to get up
and running *without configuring anything, *but I'm not sure how it can be
done in the real world (specially now that you made me aware my error on
item 1). I'd actually love to just eliminate this authorizer altogether but
it was brought to my attention that the other two proposed out of box
implementations require the user to actually configure something (the
package or the regex expression), and that we should provide some sort of
automatic trust boundary in the sense that users just deploy the domain
model, insert objects into the region, and can execute OQL invoking methods
as long as those methods belong to the objects stored within the region...
determining whether an object belongs to a region or not is fairly
complicated, not achievable right now and will certainly incur into
performance degradation, but I guess is up to the community to decide
whether we should pursue this objective or not.
As a summary, and before I go ahead and incorporate all the feedback
provided and modify the proposal, I guess the community needs to answer the
following questions:
A. For the sake of security, is it okay to force our users to do some extra
configuration steps (no matter how little or easy they might be) whenever
they deploy the domain model to the cluster and want to execute some
methods on those objects from OQL?.
B. Should we just change the approach from *deny everything* to *allow
everything *instead, and assume that users with enough privileges to
execute queries on the region (*DATA:READ:RegionName*) are trustworthy (at
the end of the day *somebody* gave them that role) and won't compromise the
security through RCE from OQL?.
If nothing changes during the weekend, I'll wait until Monday and apply the
suggested changes to the proposal in favour of a "YES" to question "A"
(just because that's my preference at the moment), sending a new email
afterward for another feedback round. Changes will still be accepted anyway
as this is just the proposal and the community as whole should deny/accept
it.
Cheers.
[1]:
https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/RestrictedMethodInvocationAuthorizer.java#L165-L171
[2]:
https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/BaseCommandQuery.java#L106-L108
On Thu, Jun 20, 2019 at 7:22 PM Dan Smith <ds...@pivotal.io> wrote:
> +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 to that?
> 2. I'm a little unclear on if your
> MethodInvocationAuthorizer.authorizeMethodInvocation is supposed to take a
> region or the target object. If it is really accepting a region, do we
> actually have a region available in all cases? We could be invoking methods
> on an object in lots of places in the query tree.
> 3. The DataAwareBasedMethodAuthorizer seems a bit vague on how it's
> actually going to work. It also might be a security risk, since it will
> allow users with DATA:READ permission to invoke any method on these
> objects.
>
> -Dan
>
> On Wed, Jun 19, 2019 at 11:34 AM Jacob Barrett <jb...@pivotal.io>
> wrote:
>
> > Thanks Juan!
> >
> > > On Jun 19, 2019, at 9:55 AM, Juan José Ramos <jr...@pivotal.io>
> 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.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
> > >
> > >> On Fri, Jun 14, 2019 at 8:39 PM Juan José Ramos <jr...@pivotal.io>
> > wrote:
> > >>
> > >> 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
> if
> > >> anyone got offended in any way.
> > >> That said, I won't have time to go through the proposal and make the
> > >> required changes until next week, so I'll keep the document hidden
> until
> > >> all biased words are replaced.
> > >> Cheers.
> > >>
> > >>
> > >> On Sat, Jun 15, 2019 at 12:25 AM Jacob Barrett <jb...@pivotal.io>
> > >> wrote:
> > >>
> > >>>> As part of GEODE-3247 <
> > https://issues.apache.org/jira/browse/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
> > not, the
> > >>> decision was made to tighten up the Security and, by default,
> disallow
> > any
> > >>> method call not explicitly whitelisted.
> > >>>
> > >>> Please avoid biased words, like whitelist, in source and proposals.
> > There
> > >>> are several other places in this document that use these terms. Can
> you
> > >>> please update the document without them.
> > >>>
> > >>> Thanks,
> > >>> Jake
> > >>>
> > >>>
> > >>
> > >> --
> > >> Juan José Ramos Cassella
> > >> Senior Technical Support Engineer
> > >> Email: jramos@pivotal.io
> > >> Office#: +353 21 4238611
> > >> Mobile#: +353 87 2074066
> > >> After Hours Contact#: +1 877 477 2269
> > >> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > >> How to upload artifacts:
> > >> https://support.pivotal.io/hc/en-us/articles/204369073
> > >> How to escalate a ticket:
> > >> https://support.pivotal.io/hc/en-us/articles/203809556
> > >>
> > >> [image: support] <https://support.pivotal.io/> [image: twitter]
> > >> <https://twitter.com/pivotal> [image: linkedin]
> > >> <https://www.linkedin.com/company/3048967> [image: facebook]
> > >> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> > >> <https://plus.google.com/+Pivotal> [image: youtube]
> > >> <
> > https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl
> >
> > >>
> > >
> > >
> > > --
> > > Juan José Ramos Cassella
> > > Senior Technical Support Engineer
> > > Email: jramos@pivotal.io
> > > Office#: +353 21 4238611
> > > Mobile#: +353 87 2074066
> > > After Hours Contact#: +1 877 477 2269
> > > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > > How to upload artifacts:
> > > https://support.pivotal.io/hc/en-us/articles/204369073
> > > How to escalate a ticket:
> > > https://support.pivotal.io/hc/en-us/articles/203809556
> > >
> > > [image: support] <https://support.pivotal.io/> [image: twitter]
> > > <https://twitter.com/pivotal> [image: linkedin]
> > > <https://www.linkedin.com/company/3048967> [image: facebook]
> > > <https://www.facebook.com/pivotalsoftware> [image: google plus]
> > > <https://plus.google.com/+Pivotal> [image: youtube]
> > > <
> > https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl
> >
> >
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Dan Smith <ds...@pivotal.io>.
+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 to that?
2. I'm a little unclear on if your
MethodInvocationAuthorizer.authorizeMethodInvocation is supposed to take a
region or the target object. If it is really accepting a region, do we
actually have a region available in all cases? We could be invoking methods
on an object in lots of places in the query tree.
3. The DataAwareBasedMethodAuthorizer seems a bit vague on how it's
actually going to work. It also might be a security risk, since it will
allow users with DATA:READ permission to invoke any method on these objects.
-Dan
On Wed, Jun 19, 2019 at 11:34 AM Jacob Barrett <jb...@pivotal.io> wrote:
> Thanks Juan!
>
> > On Jun 19, 2019, at 9:55 AM, Juan José Ramos <jr...@pivotal.io> 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.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
> >
> >> On Fri, Jun 14, 2019 at 8:39 PM Juan José Ramos <jr...@pivotal.io>
> wrote:
> >>
> >> 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 if
> >> anyone got offended in any way.
> >> That said, I won't have time to go through the proposal and make the
> >> required changes until next week, so I'll keep the document hidden until
> >> all biased words are replaced.
> >> Cheers.
> >>
> >>
> >> On Sat, Jun 15, 2019 at 12:25 AM Jacob Barrett <jb...@pivotal.io>
> >> wrote:
> >>
> >>>> As part of GEODE-3247 <
> https://issues.apache.org/jira/browse/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
> not, the
> >>> decision was made to tighten up the Security and, by default, disallow
> any
> >>> method call not explicitly whitelisted.
> >>>
> >>> Please avoid biased words, like whitelist, in source and proposals.
> There
> >>> are several other places in this document that use these terms. Can you
> >>> please update the document without them.
> >>>
> >>> Thanks,
> >>> Jake
> >>>
> >>>
> >>
> >> --
> >> Juan José Ramos Cassella
> >> Senior Technical Support Engineer
> >> Email: jramos@pivotal.io
> >> Office#: +353 21 4238611
> >> Mobile#: +353 87 2074066
> >> After Hours Contact#: +1 877 477 2269
> >> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> >> How to upload artifacts:
> >> https://support.pivotal.io/hc/en-us/articles/204369073
> >> How to escalate a ticket:
> >> https://support.pivotal.io/hc/en-us/articles/203809556
> >>
> >> [image: support] <https://support.pivotal.io/> [image: twitter]
> >> <https://twitter.com/pivotal> [image: linkedin]
> >> <https://www.linkedin.com/company/3048967> [image: facebook]
> >> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> >> <https://plus.google.com/+Pivotal> [image: youtube]
> >> <
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
> >>
> >
> >
> > --
> > Juan José Ramos Cassella
> > Senior Technical Support Engineer
> > Email: jramos@pivotal.io
> > Office#: +353 21 4238611
> > Mobile#: +353 87 2074066
> > After Hours Contact#: +1 877 477 2269
> > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > How to upload artifacts:
> > https://support.pivotal.io/hc/en-us/articles/204369073
> > How to escalate a ticket:
> > https://support.pivotal.io/hc/en-us/articles/203809556
> >
> > [image: support] <https://support.pivotal.io/> [image: twitter]
> > <https://twitter.com/pivotal> [image: linkedin]
> > <https://www.linkedin.com/company/3048967> [image: facebook]
> > <https://www.facebook.com/pivotalsoftware> [image: google plus]
> > <https://plus.google.com/+Pivotal> [image: youtube]
> > <
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jacob Barrett <jb...@pivotal.io>.
Thanks Juan!
> On Jun 19, 2019, at 9:55 AM, Juan José Ramos <jr...@pivotal.io> 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.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
>
>> On Fri, Jun 14, 2019 at 8:39 PM Juan José Ramos <jr...@pivotal.io> wrote:
>>
>> 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 if
>> anyone got offended in any way.
>> That said, I won't have time to go through the proposal and make the
>> required changes until next week, so I'll keep the document hidden until
>> all biased words are replaced.
>> Cheers.
>>
>>
>> On Sat, Jun 15, 2019 at 12:25 AM Jacob Barrett <jb...@pivotal.io>
>> wrote:
>>
>>>> As part of GEODE-3247 <https://issues.apache.org/jira/browse/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 not, the
>>> decision was made to tighten up the Security and, by default, disallow any
>>> method call not explicitly whitelisted.
>>>
>>> Please avoid biased words, like whitelist, in source and proposals. There
>>> are several other places in this document that use these terms. Can you
>>> please update the document without them.
>>>
>>> Thanks,
>>> Jake
>>>
>>>
>>
>> --
>> Juan José Ramos Cassella
>> Senior Technical Support Engineer
>> Email: jramos@pivotal.io
>> Office#: +353 21 4238611
>> Mobile#: +353 87 2074066
>> After Hours Contact#: +1 877 477 2269
>> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
>> How to upload artifacts:
>> https://support.pivotal.io/hc/en-us/articles/204369073
>> How to escalate a ticket:
>> https://support.pivotal.io/hc/en-us/articles/203809556
>>
>> [image: support] <https://support.pivotal.io/> [image: twitter]
>> <https://twitter.com/pivotal> [image: linkedin]
>> <https://www.linkedin.com/company/3048967> [image: facebook]
>> <https://www.facebook.com/pivotalsoftware> [image: google plus]
>> <https://plus.google.com/+Pivotal> [image: youtube]
>> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>>
>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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:39 PM Juan José Ramos <jr...@pivotal.io> wrote:
> 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 if
> anyone got offended in any way.
> That said, I won't have time to go through the proposal and make the
> required changes until next week, so I'll keep the document hidden until
> all biased words are replaced.
> Cheers.
>
>
> On Sat, Jun 15, 2019 at 12:25 AM Jacob Barrett <jb...@pivotal.io>
> wrote:
>
>> > As part of GEODE-3247 <https://issues.apache.org/jira/browse/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 not, the
>> decision was made to tighten up the Security and, by default, disallow any
>> method call not explicitly whitelisted.
>>
>> Please avoid biased words, like whitelist, in source and proposals. There
>> are several other places in this document that use these terms. Can you
>> please update the document without them.
>>
>> Thanks,
>> Jake
>>
>>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Juan José Ramos <jr...@pivotal.io>.
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 if
anyone got offended in any way.
That said, I won't have time to go through the proposal and make the
required changes until next week, so I'll keep the document hidden until
all biased words are replaced.
Cheers.
On Sat, Jun 15, 2019 at 12:25 AM Jacob Barrett <jb...@pivotal.io> wrote:
> > As part of GEODE-3247 <https://issues.apache.org/jira/browse/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 not, the
> decision was made to tighten up the Security and, by default, disallow any
> method call not explicitly whitelisted.
>
> Please avoid biased words, like whitelist, in source and proposals. There
> are several other places in this document that use these terms. Can you
> please update the document without them.
>
> Thanks,
> Jake
>
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [PROPOSAL]: Improve OQL Method Invocation Security
Posted by Jacob Barrett <jb...@pivotal.io>.
> As part of GEODE-3247 <https://issues.apache.org/jira/browse/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 not, the decision was made to tighten up the Security and, by default, disallow any method call not explicitly whitelisted.
Please avoid biased words, like whitelist, in source and proposals. There are several other places in this document that use these terms. Can you please update the document without them.
Thanks,
Jake