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 <jbarr...@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 <jra...@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: jra...@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>
