6 ms·

As a long time Node.js developer I took a look at the project but it's still a really half-baked implementation of the security flags. You almost always end up

As a long time Node.js developer I took a look at the project but it's still a really half-baked implementation of the security flags. You almost always end up flipping all security switches off because your application needs every feature (network, filesystem, etc). No package signing, no flags per module, no syscall whitelisting, etc.

qaq 7y ago
It's not even 1.0 yet.
- LunaSea 7y ago
  I'm not talking about the maturity of the project but more about the concept of the feature flag for security.
  - tfolbrecht 7y ago
    I like the idea from a ux perspective. It puts the control in a place where the user runs the code.
  - inglor 7y ago
    Node.js had a PR to add that in (with packages enforced but not your 'own' code) and Node has policies to deal with loading untrusted code ( https://nodejs.org/api/policy.html https://nodejs.org/api/policy.html ). Personally I isolate with OS level containers as I think it's a lot more robust and tested but I definitely see the merit in Deno exploring this - even if it doesn't really work yet it's interesting.
    - mnutt 7y ago
      I thought node.js policies were basically just SubResource Integrity hashes? Are they planning for something more? I’ve been looking into the isolated-vm module recently and it looks pretty nice. Fly.io built their run-untrusted-code service on top of it.
kevinkassimo 7y ago
You turn all permissions on if you are actually using it as if it is Node for writing servers. But in the case when you are using a (potentially untrusted) code snippet to perform certain operations (like encode/decode base64 values), you do might want a sandbox. (For the case of Node-like usage, we actually also have a basic implementation of whitelisted directories/files for certain permissions, though not perfect atm) We have also discussed about possibilities of implementing an in-memory file system. (Maybe we will also bring sessionStorage to Deno) Flags per module is slightly trickier, while whitelisting of certain feature is trivial to implement. Package signing is indeed a topic that Deno contributors need to discuss further and possibly finding a solution.
- LunaSea 7y ago
  Sure but logic doesn't exist in a vacuum so in most cases you are going to import / export your input data or your results to the filesystem or through the network. I actually suggested a more granular, per-module approach to this during the Node Forward and IO.js debacle years ago: https://github.com/node-forward/discussions/issues/14 https://github.com/node-forward/discussions/issues/14 At the time it was deemed to difficult to implement in Node.js after the fact, which makes sense of course. But I'm disappointed that Deno didn't go for a more bolder, more secure approach. The current system seems pretty pointless.
  - kevinkassimo 7y ago
    It is actually more interesting about the definition of “per module”, because technically every single file is its very own module from the view of V8, and is reinforced in Deno since we are trying to be web compatible, so there is not even a package.json-like construct for you to identify the “root” of any library, more so as there is no more index.js magical resolution
    - ZitchDog 7y ago
      Since modules are loaded from URLs, it would be per TLD.
fanf2 7y ago
Yes it’s a real shame it isn’t based on object capability security. The resource ID concept makes it really hard to do per-module restrictions, because resources provide global ambient access to anything. And it sounds to me like the dispatch model based on typed arrays means that this is baked in on a fundamental level (unless there are some unforgeable handles that Ryan didn’t mention in his talk).

qaq 7y ago

It's not even 1.0 yet.

LunaSea 7y ago
I'm not talking about the maturity of the project but more about the concept of the feature flag for security.
- tfolbrecht 7y ago
  I like the idea from a ux perspective. It puts the control in a place where the user runs the code.
- inglor 7y ago
  Node.js had a PR to add that in (with packages enforced but not your 'own' code) and Node has policies to deal with loading untrusted code ( https://nodejs.org/api/policy.html https://nodejs.org/api/policy.html ). Personally I isolate with OS level containers as I think it's a lot more robust and tested but I definitely see the merit in Deno exploring this - even if it doesn't really work yet it's interesting.
  - mnutt 7y ago
    I thought node.js policies were basically just SubResource Integrity hashes? Are they planning for something more? I’ve been looking into the isolated-vm module recently and it looks pretty nice. Fly.io built their run-untrusted-code service on top of it.

kevinkassimo 7y ago

You turn all permissions on if you are actually using it as if it is Node for writing servers. But in the case when you are using a (potentially untrusted) code snippet to perform certain operations (like encode/decode base64 values), you do might want a sandbox. (For the case of Node-like usage, we actually also have a basic implementation of whitelisted directories/files for certain permissions, though not perfect atm) We have also discussed about possibilities of implementing an in-memory file system. (Maybe we will also bring sessionStorage to Deno) Flags per module is slightly trickier, while whitelisting of certain feature is trivial to implement. Package signing is indeed a topic that Deno contributors need to discuss further and possibly finding a solution.

LunaSea 7y ago
Sure but logic doesn't exist in a vacuum so in most cases you are going to import / export your input data or your results to the filesystem or through the network. I actually suggested a more granular, per-module approach to this during the Node Forward and IO.js debacle years ago: https://github.com/node-forward/discussions/issues/14 https://github.com/node-forward/discussions/issues/14 At the time it was deemed to difficult to implement in Node.js after the fact, which makes sense of course. But I'm disappointed that Deno didn't go for a more bolder, more secure approach. The current system seems pretty pointless.
- kevinkassimo 7y ago
  It is actually more interesting about the definition of “per module”, because technically every single file is its very own module from the view of V8, and is reinforced in Deno since we are trying to be web compatible, so there is not even a package.json-like construct for you to identify the “root” of any library, more so as there is no more index.js magical resolution
  - ZitchDog 7y ago
    Since modules are loaded from URLs, it would be per TLD.

fanf2 7y ago

Yes it’s a real shame it isn’t based on object capability security. The resource ID concept makes it really hard to do per-module restrictions, because resources provide global ambient access to anything. And it sounds to me like the dispatch model based on typed arrays means that this is baked in on a fundamental level (unless there are some unforgeable handles that Ryan didn’t mention in his talk).