-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I just had to remove all my fine grained permissions because of --allow-run
changes in deno 2.
#26839
Comments
--allow-run
changes in deno 2.
Relevant docs:
The documentation above says "a full --allow-run permission will be required" but in the actual error it says "Requires --allow-all permissions" (all vs run) so maybe that error is just misleading and I could have done |
Ok yes confirmed, it does actually appear to be a bug in the error message here: Instead of removing all of my permisisons and replacing them with So it seems like the error message is just wrong, which would explain the disconnect here. Also, I still don't understand why I can't lock it down to certain subprocess names but this is far less bad than I was thinking at least. |
This is to fix a security issue. A malicious script could write to Probably your environment already had the new Deno.Command(..., {
env: {
"LD_LIBRARY_PATH": "",
"LD_PRELOAD": "",
"DYLD_FALLBACK_LIBRARY_PATH": ""
}
} |
Ok but now I have just replaced it with Also, they can't set any of the LD env vars and the .data dir is not in any of the paths in any LD env vars so how can it load any executable code it wants? Maybe those vars should just always be unset in Deno.Command and you could make the caller explicitly set them if desired? Anyway, I guess I'm unblocked but I would say the issue where the error message says |
So my env vars by default are:
So given that deno has Could it essentially detect if any path is writable and then produce this error? What if a directory under |
Here's the relevant issue: #11964
When a sub process is launched it can set any environment variable for that sub process, so as long as it can point an LD env variable at some place writable then I believe it could launch whatever code it wants.
I think it's too late to make that change, but it might have been nice (though maybe a bit confusing in some cases).
Yeah it should. I'm going to open a PR to update the message and suggest unsetting the environment variables too. |
I have a binary thats created via
So deno compile appears to create binaries dependent on |
And so you're saying that malicious script could create a file at Deno.Command('semver', { env: { LD_LIBRARY_PATH: "./data" } }) ...and it would end up trying to load their binary and arbitrary code could be run. 🤔 So I can change my flag from It appears that I can't run the tool without the path being set and I can't stop malicious code from setting it 🤔 I think the notion that allowing calls to Otherwise another possible solution might be to add another allow such as:
And then for all the You could also check if there is any overlap between the allow-write locations and the allow-ld locations and that could be forbidden also. |
Yeah and in this case, someone could just write an executable to the .data folder and run that.
It's very hard to solve this properly.
I'm thinking maybe it should check theses values on startup and only disallow launching if the values aren't the same as at startup. |
You're saying if the child process has a different ld variable than the parent process then it would get blocked? What if I actually need the subprocess to load libraries from a specific directory thats not in the parent processes LD_LIBRARY_PATH? Then I would just need to make sure that the path is included before invoking the parent and I could lock the folder location down with file system permissions to ensure its readable but not writable... 🤔 The only problem would be if the parent and the child needed to load different versions of the same library and therefore needed different paths. This seems pretty contrived though. It certainly seems like a simple solution and a welcome improvement. It would work for me and would be safe, probably most others as well. Perhaps if people encounter the more contrived scenario you have |
Yeah, it would relax the restriction only for that case. I'd like to get more feedback before doing it though (just in case it would cause more security issues).
Yeah, I think we probably need an |
For #26839
The error messages were fixed and that was probably enough to close this issue if you want. The workaround is to just use Perhaps its not worth fixing now vs later when you get more people caring but at least you have a plan of attack. Please feel free to close this if you want and thank you for your attention! |
Using git blame I am able to see this PR is the cause of this issue: #25370 @dsherret
I had an app that I upgraded from deno 1.x to 2.x in just the last couple of days and I was very dismayed to find that I had to replace all of my fine grained permissions with
--allow-all
, which I really hate.Here was my entrypoint:
And you can see it has a few
--allow-run
permissions which then causes this runtime error:So because I am calling a few subprocesses I now need to remove all of that for
--allow-run
, which will allow anything I import to call out to any domain, read and write any file on the whole operating system and invoke any child process... This is insane.I'm sorry but I get that allowing a child process to run means that you can't guarantee that that child process will be restricted to the same permissions of scripts running inside of denos process but I am explicitly stating that I am willing to take on that risk by whitelisting certain child processes. I really don't think this is remotely comparable to allowing all permissions in process.
I really don't understand how this made it through code review and strongly request that you revert this change and allow people utilize allow-run in conjunction with the other permissions. By all mean document the ramifications of allow-run and let them know that these deno permissions really only pertain to scripts running within deno itself but requiring us to remove all in process fine-grained permissions just because I'm allowing certain subprocesses to run, makes no sense at all.
If you really wanted to lock down
--allow-run
further you could maybe add the ability to specify which module is allowed to run these subprocesses so that its not available for imported scripts to run these subprocesses without being explicitly allowed to.For example:
allowing a specific module in local code
allowing 3rd party module
Please, let me choose to take on that risk without having to completely forego all in-process permission restrictions.
The text was updated successfully, but these errors were encountered: