Deno: "secure scripting environment" can be misleading

[apiel]

One of the first point on the philosophy of Deno is to claim for secure environment. Or if developer are not careful, it can actually bring to all the oposite. They might feel secure, even if they are not.
For example, if we provide --allow-run, then the script could run another instance of deno with all the permission. --allow-write could also be a problem by editing the files in ~/.deno/bin/ and giving them more permission. I wonder if then --allow-write should not be scoped to a specific folder or to have different writting flag, a secure one limited to current folder and a master one that can access as well parent folder.

Another issue, are in the distributed modules. With npm, module versions are strict and cannot be updated or removed. As soon a version is published, it is fix. So if a security as been detected, tools can inform us about them. Or with deno module, it is kind of freestyle, people can just share code as they want, release them and freely change the tags. I really like the concept of not being bound to an artifactory for my modules (it make development much easier). But would be great to have a way to make our modules consistant, maybe by signing them with a hash. So Deno would not host module, but would host the module tree representation with the hash of each files associated to a version. This would allow us to have a central source of true for our modules and a way to publish security alerts.

[ry]

--allow-run, then the script could run another instance of deno with all the permission

True - and I agree this isn't ideal. I would like Deno.run to require --allow-all to make it clearer what constraint are being released.

But would be great to have a way to make our modules consistant, maybe by signing them with a hash.

Use lock files for this https://deno.land/manual/linking_to_external_code/integrity_checking

[apiel]

Oh, I didn't know about integrity checking. But I still think that there is some stuff to do there. For example github or sonarqube can inform us about security issue with our npm dependencies. Is there anything similar in Deno?

[apiel]

Concerning --allow-run I was wondering if it be possible to use something like cgroups but after it is just like re-implementing docker inside Deno. So at the end, it feel to me like it would not make sense, Docker is there to make this kind of job, there is not point to do similar thing in Deno.

[ProdigySim]

Piggybacking on this issue with some general security-related comments:

"Secure is a verb, not an adjective" is a quote I picked up from a security talk by a Flash developer. Security is a feature of most software. I'm guessing Deno wants to advertise its security focus, but I agree with the OP that "secure scripting environment" is misleading.

Also, I have tried searching issues a little bit... Has there been any research into side channel attacks on remote module loading? Does the remote module loading prevent data exfiltration through timing of remote module loading in any way?

[ry]

"secure scripting environment" is not misleading at all. We consider it a bug if you can break out of the sandbox.

We can have better documentation about what various controls mechanisms do (like the fact that allow-run is equivalent to alllow-all), but that doesn't mean that Deno is insecure.

I'm quite certain you cannot provide an example of breaking out of a Deno program which does not have allow flags. Thus is it a secure scripting environment.

[apiel]

@ry what's about --allow-write that could edit files in ~/.deno/bin/ to give more permission?

[ry]

@apiel I'd be happy to study some examples in a separate issue specific to that case, but that has an allow flag.

I'm quite certain you cannot provide an example of breaking out of a Deno program which does not have allow flags

[apiel]

Without any allow flags I also doubt about ;-)

[ry]

Or you could provide an example of a program that can access the disk when only given --allow-net flag...

Or you could try to break out of the VM using only --allow-write and access to ~/.deno/bin (I'm rather sure you're mistaken - you cannot break out that way).

There is nothing misleading about our security claims.

[apiel]

I will give a try but i don't know when I will have time.

[ProdigySim]

I tried out some ways to influence the timing of module loads to perform a side channel attack. It looks like all import statements in a module get processed before any code executes, and dynamic import() relies on --allow-net, so finding a way to exfiltrate data via timing attacks on module loading sounds like it would be pretty hard.

[apiel]

Here you go https://github.com/apiel/deno_hack

Run deno install -f --allow-write --allow-env https://raw.githubusercontent.com/apiel/deno_hack/master/hackme.ts

Then run hackme and a second time hackme.

I had to allow environment variable to find the path of the installation folder of ~/.deno/bin/hackme but I am sure with tricking a bit around there might be some way to get this path without to ask extra permission.

This is working on Linux would have to adapt to other OS.

[nayeemrmn]

@apiel Umm, yes if you give it permission to write an executable and then run that, that's on you. Giving it permission to write the Deno executable (don't?) and then running it again is not a special case. This is the specification of the sandbox.

[apiel]

On android, if you install with the write permission, it will not allow to do anything else than writting. With Deno if you install with write permission, it give you the possibility to get all permission. So at the end deno install --allow-write === deno install --allow-all.

A way to avoid this, would be to scope where sandbox is allow to write, e.g.: --allow-write=./data/*. And we could actually do the same for reading. We could even specify a blob or a regex...
In sandboxing world, docker is a very good example, and to be able to access the file system, you have to specify the path where image can access.

[ry]

A way to avoid this, would be to scope where sandbox is allow to write

That feature is already there. Maybe this is where the confusion is coming from.

[apiel]

Oh I didn't know that...

The returned error doesn't mention it. Maybe, you should by default make --allow-write point by default to the current working directory. And only give access to the whole disk if the user specify it. After it is just a personal opinion, but from our discussion you see the kind of mistake that can happen if you don't read the whole documentation in details. Not everybody is reading the whole docs before to use the Deno (like me :p )

[kitsonk]

Because people don't read documentation doesn't make the solution insecure.

Potentially defaulting --allow-write to default to cwd is not the worst idea in the world. Opening another issue to discuss that would be the best way forward on that. It would be a breaking change, somewhat significant.