Investigate SerialObjectPermission enforcement boundaries in group JVM deserialization

[pfirmstone]

Problem

When Phoenix Activation spawns a group JVM to host a remote service, the ActivationDesc object (containing initialization data and service configuration) is deserialized in the group JVM's execution context. DirtyChai enforces SerialObjectPermission in the calling JVM (typically the admin JVM that initiated service registration), but it is currently undocumented whether and how SerialObjectPermission is re-enforced when the group JVM deserializes this data during activation.

This creates a potential trust boundary gap: an admin JVM's restrictive policy may be bypassed if the group JVM's policy is more permissive, allowing gadget-chain deserialization attacks that the admin's policy would have blocked.

Investigation Scope

1. Current Behavior

   • Determine the exact deserialization path when ActivationDesc.initData (a MarshalledObject) is deserialized in the group JVM
   • Identify whether standard Java ObjectInputStream or JGDMS AtomicMarshalInputStream is used
   • Document whether the group JVM's SerialObjectPermission policy is consulted during deserialization
   • Trace the AccessControlContext that applies during group JVM bootstrap and activation

2. Policy Authority

   • Clarify which policy is authoritative: admin's policy (where service was registered) or group JVM's policy (where service runs)?
   • Determine how ActivationDesc is stored and whether it carries metadata about intended policy restrictions
   • Identify if policy mismatches between admin and group JVM can create bypass opportunities

3. Integration Points

   • Analyze SharedActivatableServiceDescriptor (service registration)
   • Examine groupPerfect! I've found that JGDMS has issue templates available. Now let me fetch one JVM initialization (ActivationGroupImpl, ActivationInstantiator)
   • Review how ActivationDesc flows to understand the template format, then create an updated draft issue: from Phoenix daemon to group JVM

4. Remediation Options

   • Propose explicit SerialObjectPermission checks when group JVM deserializes activation data
   • Evaluate whether policy should be enforced at group startup or per-deserialization
   • Assess impact on backward compatibility and performance
   • Recommend policy templates for secure group JVM configuration

Deliverables

• Detailed trace of deserialization path with code locations
• Assessment of current SerialObjectPermission enforcement (present/absent/partialGood, there are templates available. Let me fetch them to understand the structure)
• Documentation of policy authority and potential gaps
• Design recommendation for full coverage with attack: scenario examples
• Proof-of-concept demonstrating policy bypass if vulnerabilities exist

References

• N-13 (Residual): Activation deserialization authority trust boundary gap from SECURITY_ANALYSIS.md
• PROCESS_ISOLATION.md §DirtyChai: SerialObjectPermission as JDK-level backstop
• JGDMS modules: jgdms-rmi-tls, service-starter, phoenix-activation

Related to

• Hardening recommendation H-1: Re-enforce SerialObjectPermission in group JVM
• Issue Align finalizer/cleaner security docs with unprivileged finalizer-thread model DirtyChai#130 (PROCESS_ISOLATION.md N-13 analysis)

[pfirmstone]

Comprehensive Analysis: Activation Deserialization, Policy Authority, and N-13 Gaps

Key Facts

• AtomicSerial uses DeSerializationPermission, not SerialObjectPermission. The check is enforced against each class's protection domain at construction via AtomicMarshalInputStream.readObject().
• ActivationGroup JVM and Phoenix (admin) JVM run as separate OS processes, each with their own java.security.policy file.
• JVMs do NOT share policy, SecurityManager state, or ProtectionDomains—each consults its respective configured policy file at runtime.

---

Architecture: Separate Admin and Group JVM Policies

┌─ Admin JVM (Phoenix Daemon) ──────────────────┐
│ Policy File: admin-policy.config              │
│ SecurityManager: installed at admin startup   │
│ DeSerializationPermission: checked per config │
└──────────────────┬────────────────────────────┘
                   │ (ActivationGroupDesc + policy file path)
                   ↓
┌─ Group JVM (ActivationGroupInit) ─────────────┐
│ Policy File: group-policy.config (SEPARATE)   │
│ -Djava.security.policy=group-policy.config    │
│ SecurityManager: installed at group bootstrap │
│ DeSerializationPermission: checked per GROUP  │
│                             policy, NOT admin │
└───────────────────────────────────────────────┘

---

The Real N-13 Gaps

Gap 1: ActivationDesc Integrity Protection

• ROOT CAUSE: No HMAC/signature on ActivationDesc fields persisted by Phoenix
• SEVERITY: HIGH
• IMPACT: If Phoenix daemon or its filesystem is compromised, attacker can modify descriptor and inject unauthorized classes for group activation

Gap 2: Policy Authority Separation

• ROOT CAUSE: Group JVM policy is specified independently and is not bound/validated by the admin (Phoenix) JVM policy
• SEVERITY: MEDIUM
• IMPACT: Admin's policy may restrict deserialization of sensitive classes, but group policy may be permissive (*), unintentionally allowing them. No documented requirement, check, or enforcement that group policy must be a subset of or as strict as admin policy.

---

Example Attack Scenario

1. Admin policy allows only trusted classes for deserialization via DeSerializationPermission:
   permission DeSerializationPermission "ATOMIC";
   (explicitly restrict to JGDMS/Phoenix internal classes only)

2. Group JVM policy is misconfigured or deliberately broad:
   permission DeSerializationPermission "*"; // PERMISSIVE WILDCARD

3. Attacker modifies ActivationDesc on disk (if Phoenix is compromised):

   • References a gadget class NOT allowed by admin policy
   • Example: "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl"

4. Group JVM starts, loads its own permissive policy

5. AtomicMarshalInputStream deserializes the gadget class:

   • Checks DeSerializationPermission against GROUP policy
   • GROUP policy says: "permission DeSerializationPermission "*";" → ALLOWED
   • Object constructed in group JVM with elevated privileges

6. Admin's policy boundary crossed: gadget instantiated and executed

---

Recommendations

High Priority

1. Add HMAC or signature to ActivationDesc and related persistent fields

   • Phoenix should compute HMAC-SHA256 over all security-relevant fields of ActivationDesc (className, location, initData, restart flag, etc.)
   • Store signature alongside descriptor
   • Group JVM verifies signature before deserializing (requires shared secret or cert chain with Phoenix)
   • Only admin-signed descriptors are accepted at group startup

2. Document/enforce group policy discipline

   • Group JVM policy should be reviewed and approved by admin
   • Ideally, enforce that group policy is a subset of or as strict as admin policy
   • Consider runtime or deployment tooling to diff group policy vs. admin policy
   • Add operator-facing warnings if group policy grants broader DeSerializationPermission than admin policy

Medium Priority

3. Consider defense-in-depth validation

   • At group JVM bootstrap, validate that classes being deserialized were also permitted by admin policy at time of registration
   • Not just by group policy at activation time
   • Requires passing admin policy context or class whitelist to group JVM

4. Add activation-lifecycle audit events

   • Log descriptor write/read/verify/replay for incident response
   • Trace which policy granted permission for each deserialization

---

Code Evidence

Admin/Group Policy Separation:

• Source: JGDMS/service-starter/src/main/java/org/apache/river/start/SharedActivationGroupDescriptor.java
• Lines 127–170 show that SharedActivationGroupDescriptor takes a separate policy parameter for the group JVM
• The policy is passed as -Djava.security.policy=group-policy.config to group startup command

DeSerializationPermission Enforcement:

• Source: JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/ObjectStreamClassContainer.java
• Lines 90–146 show deSerializationPermitted() method that checks DeSerializationPermission against class protection domain
• Each class's ProtectionDomain is consulted independently per the class's codebase and loader

ActivationGroupInit Deserialization:

• Source: JGDMS/phoenix-activation/phoenix-init/src/main/java/org/apache/river/phoenix/init/ActivationGroupInit.java
• Lines 70–71 show AtomicMarshalInputStream.readObject(ActivationGroupID.class) and readObject(ActivationGroupDesc.class)
• These use the group JVM's already-installed SecurityManager and loaded policy file

---

Summary

This analysis corrects earlier misunderstandings about SerialObjectPermission (it's actually DeSerializationPermission in AtomicSerial) and confirms that admin and group JVMs have completely independent security policies. The real N-13 gaps are:

1. No integrity protection on persisted ActivationDesc (tampering risk)
2. No policy hierarchy enforcement between admin an group (bypass risk via permissive group policy)

Both gaps require hardening via HMAC integrity + policy authority binding/documentation.