4 ms·
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 n
by 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 agoYou're right. Deno only has app-level permissions. We need module level too.
- kevincox 6y agoI 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.
- kevincox 6y agoHow would this work exactly? How do you control what module's permission to use for any IO? For example what if you have a callback library that calls a function that does IO? What if you pass an IO function directly as a callback? (For example File.close) If it is the file where the call is textually written how do you handle dynamic calls? (or are they forbidden). I think the capability model is probably the right one here.
- korijn 6y agoWether controls are coarse or fine (all the way to function level, or even line by line), you still need to audit the source code to see if a package is not going to abuse the permissions you grant it. Right?
- ryukafalz 6y agoNot to nearly the same extent; the key is to not grant unnecessary authority in the first place. Let's say I'm using a `left-pad` function that someone else wrote, and I'm using a system in which modules aren't granted any authority except what you give them. If I then call left-pad('foo', 5') ...I don't really have to worry that it'll go rummaging around my filesystem for my private keys and exfiltrate them somewhere. After all, I didn't give it access to my filesystem or the network! (Side-channel attacks notwithstanding, things get thorny real quick at that point.) Now, you still have to worry about the function not doing what being correct - it might return an empty string, it might go into an infinite loop, etc - but you've tremendously reduced the scope of what this module could do if the developer were malicious.
- korijn 6y agoIn obvious cases like that, I agree with you. In real life however my dependencies are rarely that simple. So let's imagine a REST API library that needs disk and network access to do it's work. How do I know it doesn't abuse my permission? And what about its transient dependencies?
- h1fra 6y agoyes while it goes in the right direction in theory, in practice it provides "almost" no additional security. the only good differentiator right now that could definitely be implemented in nodejs directly is the the flag `--allow-net=<domain>`. it could prevent data exfiltration but requires the whole stack to require this flag.