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 <dsm...@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 <jra...@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 <jhu...@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 <jbarr...@pivotal.io> > > wrote: > > > > > > > > > > > > > > > > On Jul 2, 2019, at 11:58 AM, Juan José Ramos <jra...@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: 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> > > > -- 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>
