Document update - Added serialization to Security section

[kaajaln2]

  Added serialization page under Security section
  Added link to serialization page from Security model page   Added a bullet point to the Security Implementaton Overview page

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

• Has your PR been rebased against the latest commit within the target branch (typically develop)?
  yes

• Is your initial contribution a single, squashed commit?
  yes

• Does gradlew build run cleanly?

• Have you written or updated unit tests to verify your changes?

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

[raboof]

I'm no Geode expert, so I can't fully judge the technical details, but the general change looks reasonable. One question about the mention of 'Java 8'.

[raboof]

Is this for 'exactly Java 8' or 'at least Java 8'?

If it's for 'exactly Java 8', what should operators running on later versions do?

If it's 'at least Java 8', we can remove it, as Geode doesn't support older Java versions anyway.

[JinwooHwang]

I’ve reviewed the PR and appreciate the effort put into it. To enhance clarity and impact, it may be beneficial to explicitly outline the ramifications of the default serialization configurations. For example, the current defaults allow unrestricted deserialization. Additionally, serialization filters like validate-serializable-objects and geode.enableGlobalSerialFilter are not enabled by default, which permits deserialization of custom classes without explicit whitelisting. Making these implications more visible could help readers better understand the associated security risks. @raboof, do you have any comments?

[wmh1108-sas]

To enhance clarity and impact, it may be beneficial to explicitly outline the ramifications of the default serialization configurations.

I believe the Security Model covers this by stating that serialization is off by default, and by recommending users evaluate security features individually:

"Geode’s default configuration combines maximum flexibility and performance without any input needed from the user. Because of this, certain security measures like authentication, authorization, serialization and over-the-wire encryption are absent from a default Geode installation. It is highly recommended that users review Geode’s security capabilities and implement them as they see fit."

[JinwooHwang]

Good point—the Security Model does mention that serialization is off by default and encourages users to evaluate security features individually. Since we already have a serialization section, perhaps we could use that space to remind users of the specific implications when serialization is turned on. For instance, the lack of default filters like validate-serializable-objects and geode.enableGlobalSerialFilter can lead to unrestricted deserialization. Making this more explicit could help users better assess the security posture.

[JinwooHwang]

@raboof , Please let me know if you have any questions or comments. Thanks.

[JinwooHwang]

Initiated build checks.

[raboof]

@raboof , Please let me know if you have any questions or comments. Thanks.

I don't have any strong objections. It might be good to be a bit more explicit about the fact that unrestricted deserialization of untrusted input can lead to arbitrary code execution, but I'm OK with the current wording as well.

[raboof]

AFAIK all of Geode is in Java, so (Java) is also not necessary :)

[JinwooHwang]

Restarted the failed integration test.

[JinwooHwang]

The integration test completed successfully.

[JinwooHwang]

Discussed the issues with @raboof . We’re committed to refining the document further in upcoming PRs. I’ll proceed with the merge.