[goldsteinq]

Yes, it exploits `--allow-run=whatever` + `--allow-write=whatever` to execute arbitrary code outside of the sandbox.

The problem with the Deno security model is that it’s hard to predict how granting any specific permission would affect overall security. For example, it may seem to be kinda reasonable for an application to ask for `--allow-write=~/.config` to create config directories & files, but it’s probably exploitable to escape the sandbox. Is `--allow-env` + `--allow-write=whatever` dangerous? I don’t know. If Deno runtime spawns a subprocess at some point, it could be used to execute arbitrary code via `LD_PRELOAD`. Is there a guarantee that Deno runtime will never spawn subprocesses? There is no way to know.

[skinkestek]

Lots of weasel words here and you don't answer directly.

It still seems to me that a Deno script running with necessary permissions will be a huge hurdle compared to running a Node script which by default has al permissions.

Edit : Also I'm seriously fed up with tech community cr#pping at everything good because it isn't perfect.

Today with Node any random package can download any DLL as long as it is novel enough to pass antivirus (hint: last I checked a 17 year old could make a trojan that flew straight past, no questions asked.)

Even Node is usable with the right precautions.

But trying to get people away from thinking about Deno is not ok.

[usea]

Painting any criticism of deno as simply the work of haters is much more a tactic of stopping thought.

Whether or not ideas and discussion are negative or positive is not relevant at all. When they're presented in some detail and in good faith, we should tackle them in turn. This encourages thought, discussion, and understanding among all.

[skrebbel]

GP's comment is in a thread that starts with "Deno’s permission system is broken, you shouldn’t rely on it".

Not relying on Deno's permission system will, in practice, mean just allowing everything or using Node instead of Deno. I can't for the love of god understand why that's better than using a permission system that provides some more protection than just about any other currently-commonly-used backend dev platform. Nobody at Deno is suggesting that their permission system solves all your security risk.

I bet "just allow everything" is not what the top poster intended but that's the takeaway. How many Node deployments do you know that use OS-level protections to eg disallow Node from spawning child processes?

[oefrha]

Root comment literally ended with

> If you want to isolate a program, you need to do it on the OS level.

Commenter further suggested bubblewrap and firecracker elsewhere in the thread.

“Just allow everything” is a straw man you pulled out of nowhere.

[rcxdude]

Because illusory protection is worse than no protection. if it doesn't actually provide any protection against malicious code in practice then the only thing it can give you is a false sense of security.

[goldsteinq]

I did answer directly: this exploit requires run permission with any argument and write permission to any directory. It allows malicious script to escape sandbox and execute arbitrary code outside of it.

[skinkestek]

> this exploit requires run permission with any argument and write permission to any directory. It allows malicious script to escape sandbox and execute arbitrary code outside of it.

I suppose you wrote something wrong here and I'm interested in knowing what.

Because as it stands now I read it falls down to: "If you open the permission system up extremely wide you can get exploited."

Alternatively, after thinking for a couple of minutes I can read it as "if you simultaneously allow run permission with anything and write permission with anything".

In the last case it is slightly more problematic, but if one allows a script to execute anything that is itself a huge red flag.

... and on Node this red flag is always flying by default.