Can Deno's permissions be tightened to make it easier to secure?

[MilesMcBain]

Description

I work in a government org with a fairly tight security posture. We're having difficulty getting Quarto through security audit, and one of the critical risks identified is the shipped Deno runtime.

If Quarto took a more minimalist approach to Deno permissions I could point to a plausible pathway for securing Deno using a custom .cmd pointed to by QUARTO_DENO. E.g. one that had deno --deny-net or denied reads/writes to sensitive areas of the filesystem. Direct access to deno would be blocked for other software.

Unfortunately, Quarto uses --allow-all and --unstable-ffi, both of which would prevent locking down Deno in this way.

When the Deno version allows it, it be would be useful to move to --allow-ffi=<path_to_library> and remove --allow-all if favour of --allow-read and --allow-write.

As things are now, I think the only pathway forward is to run Quarto in a container, which is a new battle to fight, and so the Security Yak Shave continues.

[cscheid]

If Quarto took a more minimalist approach to Deno permissions

That's a thing we'd love to be able to do in principle, but there's internal reasons we can't (eg compatibility with internal tooling). But, more generally, and I'm sorry to phrase it bluntly, Quarto allows you to run knitr, which allows you to run R, which is Turing complete. Focusing on the sandbox here is a red herring, and it means that if your org doesn't like the sandbox, they would hate to learn that Quarto can run knitr and jupyter.

Unfortunately, that also means that it's something you'll have to handle with your org (and so is everyone else).

[MilesMcBain]

I sympathise with your argument in my bones.

Our security team knows what Quarto does. We plan to use it with R, which we have already won support for with reasonable security controls.

We were able to do that because we have people that are intimately familiar with R. We are not, and do not care to be Javascript developers, so we are at a disadvantage arguing for Deno. We don't know the ecosystem, the community etc.

If you make it easier to lock down Deno, you make it easier for us to make our case for Quarto without going on deep dives into JS land.

As I said, I sympathise with your position, and don't want to waste your time with back and forth about it. Just giving you our perspective.

[cscheid]

I know this doesn't answer your immediate concern, but keep an eye out on https://github.com/quarto-dev/q2. I'm fairly confident that we'll switch over to Quarto 2 before we can lock Deno down in a way that works for our constraints.