Re: [PROPOSAL]: Improve OQL Method Invocation Security
Hello, Thanks for the feedback provided so far. I'm still resilient to add the *Java Security Manager* as an option, maybe it's due to my lack of experience around the subject but I still believe it is killing mosquitoes with a bazooka. We need to prevent this "bad things" only from within the OQL 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 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 wrote: > > > > > > > > On Jul 2, 2019, at 11:58 AM, Juan José Ramos > wrote: > > > > > > Hello Jake, > > > > > > I've been doing some reading about the *Java Security Manager* and, > even > > > when it might work for our use case, I don't think is a good fit due to > > the > > > following reasons: > > > 1). We already have chosen *Shiro* for 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
Re: [PROPOSAL]: Improve OQL Method Invocation Security
With Juan's proposal, the user still has the option to use java's security manager. They can install a MethodAuthorizor that allows all methods and use a java SecurityManager to restrict method access to the methods they want. Regarding the question of "How far should we go to prevent users from 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 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 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 > wrote: > > > > > > > > > > > > On Jul 2, 2019, at 11:58 AM, Juan José Ramos > > wrote: > > > > > > > > Hello Jake, > > > > > > > > I've been doing some reading about the *Java Security Manager* and, > > even > > > > when it might work for our use case, I don't think is a good fit due > to > > > the > > > > following reasons: > > > > 1). We already have chosen *Shiro* for 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. > > > >
[RELEASE] Spring for Apache Geode Release & Feature Update
Greetings Apache Geode community- I wanted to take this opportunity and let you all know about the recent developments in the *Spring* ecosystem as it relates to Apache Geode for all you *Spring* users out there. ~~ 1. *Spring Data for Apache Geode* (SDG) Lovelace-SR9 (2.1.9.RELEASE) along with SDG Moore-RC1 (2.2.0.RC1) are now available. SDG handles all your data management needs (e.g. data access). Notable changes include: 1.1. DATAGEODE-168 - Adds support to configure GatewayReceivers with the Annotation-based configuration model. [1] -- Thank you *Udo Kohlmeyer* for the PR. 1.2. DATAGEODE-183 - Upgrades SDG Moore to Apache Geode 1.9.0. [2] 1.3. DATAGEODE-184 - Applies RegionConfigurers to Caching-defined *Regions*. [3] 1.4. DATAGEODE-187 - Ability to configure and bootstrap dedicated Locator, *Spring (Boot)* applications using the new @LocatorApplication annotation. [4] 1.5. DATAGEODE-190 - Adds support for configuring the SSL default context provided by the JRE. [5] -- Thank you *Srikanth Manvi* for the PR. 1.6. DATAGEODE-192/194 - Adds support for securing (HTTPS) and authenticating the HTTP connection as well as following HTTP redirects. [6], [7] 1.7. Usual dependency updates aligning with *Spring Boot* 2.1 and 2.2, respectively. See the *changelog* [8] for complete details. 2. *Spring Session for Apache Geode* (SSDG) 2.1.4.RELEASE and 2.2.0.M2 available. SSDG handles all your (HTTP) Session state caching needs. Notable changes include: 2.1. Issue #38 - Adds support to disable client subscriptions and interests registrations to minimize the network traffic between client & server. [9] 2.2. Issue #39 - Adds support for SessionChangeEvents (not provided in the core Spring Session framework itself). 2.3. The usual dependency updates aligning with *Spring Boot* 2.1 and 2.2, respectively. 3. *Spring Test for Apache Geode* (STDG) 0.0.5.RELEASE. STDG can be used for all your *Unit & Integration* testing needs with Apache Geode in a *Spring* context. Notable changes include: 3.1. ICYMI, Adds support for mock *Region* data and mocking basic *Region* operations (e.g. *get* & *put*). [10] -- This is particularly useful when testing your application SD[G] *Repositories* and performing basic CRUD data access operations. 3.2. Adds support for calling your custom application callbacks (e.g. CacheLoader, CacheWriter and CacheListeners) from a *mock* Region. [11] 3.3. Adds support asserting application log statements. [12] 4. *Spring Boot for Apache Geode* (SBDG) 1.0.1.RELEASE and 1.1.0.M3 available. SBDG just makes everything easier to do when building *Spring* applications using Apache Geode. Notable changes include: 4.1. Issue #36 - Adds Spring Boot Starters for STDG. [13] 4.2. Issue #38 - Adds Spring Boot Starters for SSDG. [14] 4.3. Issue #40 - Auto-configuration for logging. [15] 4.4. Issue #26 - Adds dedicated support for *Inline Caching* based on SD Repositories. [16] -- See Documentation [17] for more details. 4.5. Issue #31 - Auto-configures templates for all configured Geode Regions. [18] -- See Documentation [19] for more details. 4.6. Issue #33 - Adds support to deploy Spring Boot, Apache Geode apps to Pivotal CloudFoundry, but connect those apps to a externally managed, standalone Apache Geode cluster. [20] See *changelog* [21] for complete details. ~~ As you can see, much is happening in the *Spring* ecosystem revolving around Apache Geode. If you are wondering where to start, start with Spring Boot (i.e. SBDG). It is the simplest way to get started quickly and reliably. As always, feedback is most welcomed and appreciated. Regards, -- -John [1] https://jira.spring.io/browse/DATAGEODE-168 [2] https://jira.spring.io/browse/DATAGEODE-183 [3] https://jira.spring.io/browse/DATAGEODE-184 [4] https://jira.spring.io/browse/DATAGEODE-187 [5] https://jira.spring.io/browse/DATAGEODE-190 [6] https://jira.spring.io/browse/DATAGEODE-192 [7] https://jira.spring.io/browse/DATAGEODE-194 [8] https://github.com/spring-projects/spring-data-geode/blob/master/src/main/resources/changelog.txt [9] https://github.com/spring-projects/spring-session-data-geode/issues/38 [10] https://github.com/spring-projects/spring-session-data-geode/issues/39 [11] https://github.com/spring-projects/spring-test-data-geode#mock-region-callbacks [12] https://github.com/spring-projects/spring-test-data-geode#asserting-logging-behavior [13] https://github.com/spring-projects/spring-boot-data-geode/issues/36 [14] https://github.com/spring-projects/spring-boot-data-geode/issues/38 [15] https://github.com/spring-projects/spring-boot-data-geode/issues/40 [16] https://github.com/spring-projects/spring-boot-data-geode/issues/26 [17] https://docs.spring.io/spring-boot-data-geode-build/1.1.x/reference/html5/#geode-caching-provider-inline-caching [18] https://github.com/spring-projects/spring-boot-data-geode/issues/31 [19] https://docs.spring.io/spring-boot-data-geode-build/1.1.x/ref
