Keeping data private?

Questions / Help
, ,
1

This is an open question, but it’s something I’ve been thinking about as I play around with processes and state for a game. (Background: I’ve got multiple “player” modules/processes competing in a “game” of survival).

Sometimes, I want certain bits of data to be “private”, so that other processes cannot read it or write to it. In my case, a player module might need to know some things about another player module in order to “compete” against it, but as soon as you know the other player’s PID, it might be possible to see data that you’re not supposed to see or worse, to overwrite data. (This scenario might make more sense if I asked 100 people to each contribute their own player module to a “tournament” – the code won’t work if they don’t implement the defined behaviours/callbacks, but there’s no guarantee that people won’t peek into the PIDs).

So my question is: What strategies are there in Elixir/Erlang for keeping data private? The only thing that comes to mind is the simple (albeit sometimes tedious) structuring of code that would ensure:

  1. only passing along bits of data that is safe to be read
  2. being very careful when dispatching execution that updates data
  3. guarding PIDs carefully (i.e. don’t reveal them unnecessarily)

Related question: Is there any way to enumerate PIDs? Just eyeballing my simple spawned processes, it looks the the PIDs are very much incremental. How would one go about about enumerating PIDs? Coming from a cybersecurity background, it doesn’t appear that it would be difficult to start guessing PIDs and eventually find one that I could use to read or update data (e.g. on another player, in the case of my game). I could rework the “game” code in my case so that player processes were stopped and started to minimize peeking, but it wouldn’t eliminate the possibility (and it would vastly complicate/slow-down the code).

Thoughts?

2

Two quick answers:

  • there is no way for a process for hide, you can get the pids of all processes, all processes, with Process.list()
  • the process heap is private to the process so another process cannot directly access it without asking the process for it.

Note that a process’s process dictionary and it’s message queue using Process.info(pid)

2 Likes
3

There is absolutely no protection in the beam against untrusted code. Any process can just Process.list and then call VM functions to look at them. Now, that doesn’t mean that any process can just “write to the state” of some other process. A process is still the only thing that can write to its own heap. Other processes can send send some pid P messages but it’s entirely up to P what it does with those messages and whether it updates its internal state.

If you’re teaching a class or something it’d probably be fine to just tell people “you’ll be penalized if you intentionally mess with other people’s pids in a nefarious way”. If you’re accepting code from people on the internet I’d uh, not accept code from people on the internet. The beam just simply wasn’t built for running untrusted code.

P.S. However, all of those dire warnings were based on the idea that the code you’d be running was elixir / erlang code. If you let folks write their logic in Lua then you could use GitHub - rvirding/luerl: Lua in Erlang inside processes to execute that lua, and that should be perfectly safe as long as you don’t intentionally expose dangerous functions to the lua / erlang bindings.

5 Likes