I’m not a fan of Deno’s security model (2024)

I recently had the opportunity to reflect on my thoughts regarding Deno's security model, specifically focusing on its permission system. Deno is a language runtime for JavaScript, which includes a standard library, package manager, TypeScript transpiler, and other components. However, it's not a JavaScript implementation, meaning it doesn't interpret or compile JavaScript; instead, it relies on V8 for those tasks.

One of Deno's flagship features is its permission system, which is highlighted on their landing page under the "Secure by default" header. This system allows Deno to choose which accesses it allows or disallows for code running within the standard library. For example, it can restrict code.ts to only reading /tmp/dir and running uname. Furthermore, a program can request permissions at runtime, prompting users with a clear message in the terminal when needed.

However, I believe this approach is fundamentally insecure and misleading. The most apparent concern arises from the fact that Deno displays the permission prompt directly in the terminal, rather than using a more secure interface like PolKit GUI window. This design choice allows malicious code to send arbitrary commands to the terminal via stdout and potentially manipulate the terminal's colors or responses, making it difficult for users to discern genuine prompts from malicious ones.

Additionally, Deno allows programs to print arbitrary data to stdout and read from stdin without any filtering, making it easy for attackers to send malicious commands to the terminal. While this feature may be useful in certain contexts, it introduces significant security risks, as malicious code could potentially trick users into pre-feeding approval into stdin or even manipulate the operating system's dynamic loader to execute arbitrary code.

This illustrates that Deno's permission system, despite its intentions, creates a weakness in the overall security model, making it vulnerable to attacks.