6 ms·

I believe that Deno (the "successor" to Node being written by Ryan Dahl) is supposed to fix this for server-side JavaScript/TypeScript. It doesn't grant any per

by easton 6y ago

I believe that Deno (the "successor" to Node being written by Ryan Dahl) is supposed to fix this for server-side JavaScript/TypeScript. It doesn't grant any permissions to anything unless you specifically give them out (so you can say that only a specific module gets access to the filesystem, for instance, and on top of that it can only access /srv and not /etc). https://deno.land/manual@v1.7.2/getting_started/permissions https://deno.land/manual@v1.7.2/getting_started/permissions

nogbit 6y ago
I think this is critical. The actual runtime of any code needs to do way more than what it’s doing now. Simply relying on package signing and the like permits trusted but malicious actors. With Deno packages configured well it can really lock down and limit a ton of attack vectors.
- salawat 6y ago
  >trusted but malicious actors I...think you might have bigger problems going on there. You're tryingto throw a tech solution at a problem that is fundamentally human in nature. That tends to leave nobody satisfied.
  - josephg 6y ago
    Tech solutions are the best solutions when they work! Fighting with your spouse over who does the dishes? Buy a dishwasher! Don’t want your ISP snooping on traffic? Use https / a VPN! Unfortunately, package signing does nothing to protect against the threat vector presented here. The authentication system in npm is working fine. The problem is we put too much trust in software from the internet.
    - salawat 6y ago
      ...Hence my classification of it as a human problem. I apologize, this is a quirk of my personal vernacular. This is a problem that emergently arises out of the way human beings interact with each other socially, even before tool use comes into the picture. Alice has a thing. Bob had a thing that Alice figured would make her life easier so integrates it without looking too hard at it. Alice didn't reallize that by adding Bob's thing, something Alice wanted private was no longer the case even if her primary use case was solved. The technical solution is making Alice's thing include a really onerous to configure permissions framework that takes the work of getting a thing set up and increases the task list from program thing to program and configure permissions for thing. The human solution is to realize you don't know Bob from Adam, or his motivations, and to observe what Bob's thing actually does. Then depending on criticality, remake something similar, or actually take the time to get to know Bob and see if he can make what you want for you under some sort of agreement that facilitates good business and trust all around. You can't be sampling for malicious changes in real-time, so it's all about risk management. The issue in our case, is a lot of these projects are essentially gifts with no active attention paid to them after a certain point. It's a variant of cargo cults. You want this thing? Go here, get that, presto. Businesses, developers, (and their exploiters) like that. The price though is that once a project is abandoned, and the rights transferred to someone you don't know, you have to rerun your risk management calculation again. The thing people should be worried about is all the PHB's (pointy-haired bosses) who just got ammo for their NMIH (Not-Made-In-House) cannons now that supply chain attacks are becoming increasingly visible vectors for attack.
      - salawat 6y ago
        In a rare self-reply, this feeds into the reason why I scratch my head at the whole license based IP distribution thing. By bringing licenses into it, you push for a business relationship first, but discourage further toolmaking. Programs are math. Rederivation and application should really be the norm, but can't be if we're drawing boxes around arrangements of symbols and saying "Do not cross." It's the weird contradiction at the core of what we do as software people that still keeps me scratching my head. We all run to make a hydrant to mark, then try to make rent extracting business around it instead of maximizing the number of variants of hopefully practical and efficient ways to allow everyone else to solve their own problems. I'm not against people being able to make a living doing what they love, but the incentive structure seems all out of jibe with what I understood to be the overall goal. Or something. Still wrapping my head around it I guess.
    - Gehinnn 6y ago
      What about reviews and review certificates then? If you review a the package foo@1.0 you could publicly certify that it is not malicious and maybe earn some money with it. In turn, you back your claim with a financial security that you pay in case the package actually contains malicious code.
      - josephg 6y ago
        Thats a great idea - but in a centralized system like npm or cargo you don't need certificates to implement that. (Certs might be a nice implementation though.) So yeah, there might be a "trusted security reviews with payments" shaped technical solution. I'd love to see someone flesh that out - that sounds like a potential solution to this problem (unlike developer-signed packages).
ryukafalz 6y ago
This looks like it's... getting there, but still too coarse-grained. It looks like those permissions are granted to the whole Deno process? So if your program needed both access to sensitive data on the filesystem and network access, and it used a malicious dependency, that dependency could take advantage of those permissions and exfiltrate that data. I could be wrong, but I don't see any mention of permissions on imported code: https://deno.land/manual@v1.7.2/examples/import_export https://deno.land/manual@v1.7.2/examples/import_export
- jonny_eh 6y ago
  You're right. Deno only has app-level permissions. We need module level too.
  - kevincox 6y ago
    I think it could be something like only the root module could import net, fs, os... then in order for modules to access those things the root module would need to pass it in explicitly. Of course if you don't import the module at all there is no access. Of course JS isn't a great language for this. A malicious program could spider the object graph looking for something valuable. You would have to be very careful to keep these objects hidden. And a container library would have huge amounts of access with it needs none. (For example if you want to store a hashmap of open sockets) A stronger typed language like Rust or Haskell could do better, as you container library can be prevented from casting T to File. However even that is not enough as you can just manually cast a pointer if you somehow know what type it is. (And there is a small amount of reflection that can do this even in safe code).
    - jonny_eh 6y ago
      > Of course JS isn't a great language for this. A malicious program could spider the object graph looking for something valuable. Deno can provide extra syntax or annotations for imports to allow the dev to explicitly allow permission per-import. These can be in the source code, or in a config file.

by easton 6y ago

nogbit 6y ago

I think this is critical. The actual runtime of any code needs to do way more than what it’s doing now. Simply relying on package signing and the like permits trusted but malicious actors. With Deno packages configured well it can really lock down and limit a ton of attack vectors.

salawat 6y ago
>trusted but malicious actors I...think you might have bigger problems going on there. You're tryingto throw a tech solution at a problem that is fundamentally human in nature. That tends to leave nobody satisfied.
- josephg 6y ago
  Tech solutions are the best solutions when they work! Fighting with your spouse over who does the dishes? Buy a dishwasher! Don’t want your ISP snooping on traffic? Use https / a VPN! Unfortunately, package signing does nothing to protect against the threat vector presented here. The authentication system in npm is working fine. The problem is we put too much trust in software from the internet.
  - salawat 6y ago
    ...Hence my classification of it as a human problem. I apologize, this is a quirk of my personal vernacular. This is a problem that emergently arises out of the way human beings interact with each other socially, even before tool use comes into the picture. Alice has a thing. Bob had a thing that Alice figured would make her life easier so integrates it without looking too hard at it. Alice didn't reallize that by adding Bob's thing, something Alice wanted private was no longer the case even if her primary use case was solved. The technical solution is making Alice's thing include a really onerous to configure permissions framework that takes the work of getting a thing set up and increases the task list from program thing to program and configure permissions for thing. The human solution is to realize you don't know Bob from Adam, or his motivations, and to observe what Bob's thing actually does. Then depending on criticality, remake something similar, or actually take the time to get to know Bob and see if he can make what you want for you under some sort of agreement that facilitates good business and trust all around. You can't be sampling for malicious changes in real-time, so it's all about risk management. The issue in our case, is a lot of these projects are essentially gifts with no active attention paid to them after a certain point. It's a variant of cargo cults. You want this thing? Go here, get that, presto. Businesses, developers, (and their exploiters) like that. The price though is that once a project is abandoned, and the rights transferred to someone you don't know, you have to rerun your risk management calculation again. The thing people should be worried about is all the PHB's (pointy-haired bosses) who just got ammo for their NMIH (Not-Made-In-House) cannons now that supply chain attacks are becoming increasingly visible vectors for attack.
    - salawat 6y ago
      In a rare self-reply, this feeds into the reason why I scratch my head at the whole license based IP distribution thing. By bringing licenses into it, you push for a business relationship first, but discourage further toolmaking. Programs are math. Rederivation and application should really be the norm, but can't be if we're drawing boxes around arrangements of symbols and saying "Do not cross." It's the weird contradiction at the core of what we do as software people that still keeps me scratching my head. We all run to make a hydrant to mark, then try to make rent extracting business around it instead of maximizing the number of variants of hopefully practical and efficient ways to allow everyone else to solve their own problems. I'm not against people being able to make a living doing what they love, but the incentive structure seems all out of jibe with what I understood to be the overall goal. Or something. Still wrapping my head around it I guess.
  - Gehinnn 6y ago
    What about reviews and review certificates then? If you review a the package foo@1.0 you could publicly certify that it is not malicious and maybe earn some money with it. In turn, you back your claim with a financial security that you pay in case the package actually contains malicious code.
    - josephg 6y ago
      Thats a great idea - but in a centralized system like npm or cargo you don't need certificates to implement that. (Certs might be a nice implementation though.) So yeah, there might be a "trusted security reviews with payments" shaped technical solution. I'd love to see someone flesh that out - that sounds like a potential solution to this problem (unlike developer-signed packages).

ryukafalz 6y ago

This looks like it's... getting there, but still too coarse-grained. It looks like those permissions are granted to the whole Deno process? So if your program needed both access to sensitive data on the filesystem and network access, and it used a malicious dependency, that dependency could take advantage of those permissions and exfiltrate that data. I could be wrong, but I don't see any mention of permissions on imported code: https://deno.land/manual@v1.7.2/examples/import_export https://deno.land/manual@v1.7.2/examples/import_export

jonny_eh 6y ago
You're right. Deno only has app-level permissions. We need module level too.
- kevincox 6y ago
  I think it could be something like only the root module could import net, fs, os... then in order for modules to access those things the root module would need to pass it in explicitly. Of course if you don't import the module at all there is no access. Of course JS isn't a great language for this. A malicious program could spider the object graph looking for something valuable. You would have to be very careful to keep these objects hidden. And a container library would have huge amounts of access with it needs none. (For example if you want to store a hashmap of open sockets) A stronger typed language like Rust or Haskell could do better, as you container library can be prevented from casting T to File. However even that is not enough as you can just manually cast a pointer if you somehow know what type it is. (And there is a small amount of reflection that can do this even in safe code).
  - jonny_eh 6y ago
    > Of course JS isn't a great language for this. A malicious program could spider the object graph looking for something valuable. Deno can provide extra syntax or annotations for imports to allow the dev to explicitly allow permission per-import. These can be in the source code, or in a config file.