[PR] fix: check the remote deployment allow list before deserializing constructor args [pekko]

["pjfanning (via GitHub)" <gi...@apache.org>]

pjfanning opened a new pull request, #3493:
URL: https://github.com/apache/pekko/pull/3493

   ### Motivation
   `DaemonMsgCreateSerializer.fromBinary` resolved the peer-named actor class and then deserialized **every constructor argument** — each with a peer-chosen serializer id and manifest — before `RemoteSystemDaemon` consulted the remote deployment allow list (`RemoteDaemon.scala`).
   
   So for a class the allow list rejects, a peer still got arbitrary nested deserialization performed on its behalf, for a deployment refused moments later. That weakens the guarantee the allow list is credited with: the check exists to bound what a peer can cause this node to do, but the surface-bearing work happened before it.
   
   (For the avoidance of doubt: class *loading* here is `Class.forName(fqcn, false, loader)` — `initialize = false` — so static initializers do not run. The argument deserialization is the part worth moving.)
   
   ### Modification
   - Extract `RemoteDeploymentAllowList` (INTERNAL API, in `RemoteDaemon.scala` beside the related exception): it owns the two **existing** config keys — `pekko.remote.deployment.enable-allow-list` and `…allowed-actor-classes` — and the `getCanonicalName` comparison.
   - `RemoteSystemDaemon` and `DaemonMsgCreateSerializer` both use it, so the two sites cannot drift on either the keys or the comparison.
   - The serializer checks the allow list immediately after resolving the actor class and **before deserializing any argument**, logging at `error` with `LogMarker.Security` and throwing the same `NotAllowedClassRemoteDeploymentAttemptException` the daemon raises. `RemoteSystemDaemon` keeps its check as defence in depth.
   
   No new configuration. With the allow list off — the default — behaviour is unchanged.
   
   ### Result
   With the allow list enabled, a rejected class is refused before any peer-supplied constructor argument is deserialized. The deployment is still refused, with the same exception and the same security-marked log signal, wherever it is caught.
   
   ### Tests
   - `sbt "remote/testOnly …DaemonMsgCreateSerializerAllowListSpec …DaemonMsgCreateSerializerAllowListDisabledSpec"` — new specs, including one that registers a counting serializer for the constructor argument and asserts the count stays at zero for a rejected class (the ordering this change is about), plus a disabled-allow-list spec pinning the default behaviour
   - `sbt "remote/testOnly org.apache.pekko.remote.classic.RemoteDeploymentAllowListSpec …AllowJavaSerializationSpec …NoJavaSerializationSpec"` — existing specs pass unchanged, including the end-to-end allow-list rejection
   - `sbt "remote/mimaReportBinaryIssues"` — no issues
   
   ### References
   Refs #3478
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org
For additional commands, e-mail: notifications-help@pekko.apache.org

Re: [PR] fix: check the remote deployment allow list before deserializing constructor args [pekko]

["pjfanning (via GitHub)" <gi...@apache.org>]

pjfanning merged PR #3493:
URL: https://github.com/apache/pekko/pull/3493


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org
For additional commands, e-mail: notifications-help@pekko.apache.org