-
Notifications
You must be signed in to change notification settings - Fork 29k
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
macOS entitlements and entries for Info.plist disallow developing and running certain types of apps via VSCode #119787
Comments
Thanks for the detailed issue report, this is another variation of #95062. I haven't enabled these entitlements mainly because of the permission model around it, once a user grants these permissions to the app it is not only gonna help the terminal process but also other untrusted processes, specifically in our case the extension process. Say for example a bad extension wants to use some apple events or media device access, to a user the permission dialog will only mention that vscode wants this permission, there is no way to intercept this flow currently within vscode and explicitly tell the user who is asking for it and why. Alternatively if I can enable these entitlements on a particular helper executable and not for the app, it would also allow some granularity to control these permissions for the app. It is unfortunate that the vscode terminal is expected to behave as the OS terminal but the permissions are tied down because of the app. I am happy to explore solutions that would not give the extension process these privileged entitlements. Is it not possible to execute your app from the vscode terminal using the Launchservice (ex: open) that would ensure the app process is not related to vscode. |
Thanks for your time! Security was on my mind
hence I mentioned that Accessibility and Screen Recording passes though. It already is a game where if user trusts VSCode in those areas, then the user is stripped naked for a rogue processes, be extensions or from within terminal. I can get all the data about user activity, mouselog, keylog via VSCode (via other means than AE, Having those permissions already open probably is not a strong argument for enabling AE access, enabling yet another potential attack type via VSCode. I understand and respect your stance that VSCode has to do everything it can to protect the developer from malicious extensions, although I do not necessarily agree with it. I would set that responsibility on developer to choose wisely, disallowing AE is like shutting down pet door to an house while leaving open all the other doors, garage and windows. We are dealing Nodejs under the hood too, this is not i.e. Deno.
I will think about it. For example macOS 11 now comes with some new ways of doing things regarding permissions, but still the API regarding reading, asking for and self-disalowing is still unfinished. If there was a solution it would be hacky, I'm pulling my hair out how unfinished and rushed things are from Apple side for security-related APIs since changes in 10.15. One instant idea that comes into mind is Other idea is that VSCode implements yet another "helper" - a custom app bundle that sits along Hopefully you will not close this ticket, let it marinate a bit.
Yes and No. No. It is an Electron project developed in VSCode. In development everything is watched, live reloaded, transported to console etc
Yes. But that would bring out the process in such a manner that VSCode terminal is not needed any more - back to ground zero, where VSCode for text editing, and some other terminal (Terminal / iTerm / whatever) for running and observing. |
Sorry for the delayed response, we had discussed this internally and decided to enable the following entitlements.
|
Thank you! Apart from entitlements
They could be reformulated though for uberclarity if one knows that VSCode itself will not use those features This app needs access to (AppleScript | the camera | the microphone) => ⚠ An extension or a process in terminal within Visual Studio Code wants to use (AppleScript | your camera | your microphone). By allowing this feature you allow all future requests of this type from any process within Visual Studio Code. You can disable this permission at any time in System Preferences. ⚠ or smth like that. Decorated with U+26A0 ( FYI to reset permissions programmatically (which would allow VSCode to have a menu entry under Preferences or Help to disallow itself)
or just
full list (will differ based on os version)
|
Given that these access in most situations are performed under a user triggered action in the terminal or extension they have installed, I don't think we need to be specific in the wording and just follow suite of what other mac IDE apps do.
I don't think we want to add these helpers to the app. A user should just default to the OS for clearing these permissions and not look for way to perform it from within the app. |
/verified |
Steps to Reproduce:
NSAppleScript
. In my case it is an Electron project thatspawn
s multiple native binaries written in Swift where one of them usesNSAppleScript
and pipes data between Electron main process and native runtime.entitlement
Info.plist entry
N.B. Entries
NSAppleScriptEnabled
andOSAScriptingDefinition
are different beasts.com.apple.security.*
cases might fail Apple docs on Hardened RuntimeIMHO, VSCode should open up permissions as its terminal serves for live debugging apps that may ask different kind of permissions to OS. Due to the very nature of VSCode I consider this to be a bug not missing feature.
Does this issue occur when all extensions are disabled?: Yes
The text was updated successfully, but these errors were encountered: