Security model about distributed-closure HOT 3 CLOSED

I think the key problem is that any module can make its own static pointers and GHC does not mandate that only the main program is allowed to do so.

Sounds like the cause for some problem. But could you state what the problem is? You seem to have a concern about security. But from this description I haven't pinned down what it is exactly quite yet.

from distributed-closure.

If so, what can I do to restrict the functions that I can get from unclosure?

As a stopgap, you could check the origin of the StaticPtr at runtime after looking it up (unsafeLookupStaticPtr) and before dereferencing it (deRefStaticPtr) with staticPtrInfo.

from distributed-closure.

OK, to clarify:

Let's say my program uses some external package that makes some static pointer that I don't know about. The program receives from an untrustworthy environment some serialized data encapsulating some closure in a request signify something for my program to run (maybe as part of an RPC system or a job queue system). The closure received typically involves some static pointer that I make in my own modules for the functions I want to allow running through closures. An attacker sends me a binary blob encoding some closure that involves some static pointer from the external package instead of my modules and the types line up, so I successfully deserialize the binary blob into a closure, and then end up naively running the closure and doing things I don't mean to do.

I would like to confirm whether that the above scenario is indeed possible and that a safety measure like the one mentioned by @facundominguez is necessary for security.

from distributed-closure.