Design security mechanism for remote code execution

[Damián Silvani]

Currently there is a serious security issue with the evaluation pub sub mechanism. A malicious user can run code in the machine running a REPL client.

[Damián Silvani]

I don't think this is easily solvable by making flok REPL-agnostic. The only secure way I see is to use sandboxes for each REPL, but I think this goes beyond the scope of Flok and it's the user responsability in any case. What Flok could do is make it harder for malicious users to take advantage of this.

Some ideas:

• Invite-only sessions: User creates a session and flok builds a symmetric hash that contains session attributes. To make sure nobody can reproduce the hash from reading flok's source code, we could use some secret salt (configured with an env variable).
• Password: User A creates a session with a password, and flok includes the hashed password inside the session attributes. Now, user B enters via the invite link, and asks for the password. Flok verifies if the hashed password matches with the one contained in the session attributes.
• Peer whitelist: User creates a sesssion with a peer whitelists of IPs. Adds an extra security layer.

I believe implementing invite-only sessions + passwords is a good solution all in all for the scope of this project.

[Damián Silvani]

I came up with a simpler solution:

1. User creates a session. Flok may optionally ask the user for some properties and features, like the layout, targets, and enabled extensions. When accepting, Flok automatically creates an invite token for the session, stores all the session attributes locally (local storage or cookies), then goes to the editor.
2. On the editor, Flok joins the WebRTC room and tries to store the session attributes stored on the browser in a special Yjs document. Then, it displays a modal showing the invite token, and for easier access, an invite URL for other peers. It also shows instructions on how to run flok-repl for this particular session (e.g. depending on the specified targets, the command line arguments needed).
3. When another user wants to join, they can enter the invite token from the home page, or join via the invite URL directly.
4. After joining a session, Flok joins the WebRTC room and tries to retrieve the session attributes. If the document does not exists, returns 404 and redirects to home page. Otherwise, it shows basic session info (targets and enabled extensions) and asks the user for their nickname. When accepting, Flok goes to the editor, and displays a modal with info about how to set up flok-repl (similar to the user who created the session).

[Ondřej Kuhejda]

I don't think this is easily solvable by making flok REPL-agnostic. The only secure way I see is to use sandboxes for each REPL, but I think this goes beyond the scope of Flok and it's the user responsability in any case. What Flok could do is make it harder for malicious users to take advantage of this.

Some ideas:

• Invite-only sessions: User creates a session and flok builds a symmetric hash that contains session attributes. To make sure nobody can reproduce the hash from reading flok's source code, we could use some secret salt (configured with an env variable).
• Password: User A creates a session with a password, and flok includes the hashed password inside the session attributes. Now, user B enters via the invite link, and asks for the password. Flok verifies if the hashed password matches with the one contained in the session attributes.
• Peer whitelist: User creates a sesssion with a peer whitelists of IPs. Adds an extra security layer.

I believe implementing invite-only sessions + passwords is a good solution all in all for the scope of this project.

I managed to execute Tidal Cycles and Flok inside a container (for improved security and easier installation). Here is my Dockerfile: https://github.com/kuhy/tidalbox