macOS entitlements and entries for Info.plist disallow developing and running certain types of apps via VSCode

[kroko]

• VS Code Version: 1.54.3
• OS Version: macOS 10.15.7 (19H524)

Steps to Reproduce:

1. macOS specific
2. Develop a project in VSCode that somewhere down the chain uses call to NSAppleScript. In my case it is an Electron project that spawns multiple native binaries written in Swift where one of them uses NSAppleScript and pipes data between Electron main process and native runtime.
3. Run the project through VSCode terminal (in my case it is live reloading Electron project).
4. macOS security system will not ask user permission to allow access for VSCode to some other apps AE dictionary.
5. Yes, VSCode, not the app developed via VSCode, because VSCode encapsulates the process and spawned subprocesses, it is the main bundle in this case.

• When some process wants to access AE dictionaries for other apps a permission to macOS is asked which in turn results in permissions dialog represented to user. Permission can be denied or granted, and the entry with chosen allowance will show up in Automation anchor under System preferences : Security & Privacy.
• In order for this to work the bundle that encapsulates the runtime that uses AE has to have

entitlement

<key>com.apple.security.automation.apple-events</key>
<true/>

Info.plist entry

<key>NSAppleEventsUsageDescription</key>
<string>Bla bla</string>

N.B. Entries NSAppleScriptEnabled and OSAScriptingDefinition are different beasts.

• Due to VSCode entitlements and Info.plist settings the call will not go through, that is - process running in VSCode terminal will not signal macOS gatekeeper that permission to access specific app AE is asked, user (in this case a developer using VSCode) will not be notified, System preferences : Security & Privacy : Automation will not populate, and app development/debugging cannot happen.
• Note that current VSCode setup passes through subprocesses that need Accessibility and Screen Recording permissions (I use them in my binaries, too) - System preferences : Security & Privacy anchors Accessibility and Screen Recording will populate. Not relevant to me, but I imagine that other permissions under com.apple.security.* cases might fail Apple docs on Hardened Runtime

IMHO, 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

[deepak1556]

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.

[kroko]

Thanks for your time!

Security was on my mind

permission dialog will only mention that vscode wants this permission

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, NSEvent.addGlobalMonitorForEvents, NSWorkspace.shared.notificationCenter observers, CoreGraphics and other beasts), I know that first hand - the very Electron app I develop spawns native binaries that I have written that do that by design.

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.

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. I am happy to explore solutions that would not give the extension process these privileged entitlements.

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 tccutil. tccutil reset AppleEvents com.microsoft.VSCode on every launch, thus every developer session in VSCode gets flushed permissions for AppleScript (and tccutil reset ScreenCapture, tccutil reset Accessibility too). Thus VSCode user gets poked quite a lot if any extension uses AppleScript and maybe one will think twice, why the hell VSCode asks for it. <key>NSAppleEventsUsageDescription</key> can contain UTF8 emojis bringing attention to think twice too. 😸 ⚠️

Other idea is that VSCode implements yet another "helper" - a custom app bundle that sits along Code Helper.apps, call it SecurityHelper.app. It would be some kind of middleware - it exposes endpoint that must be used by any extension that wants to call applescript, extension sends in serialised json containing whoami and eastringtoexecute, middleware decides to execute or not and if yes does that and returns result. Then again - so much stuff to do for only one platform and only one potential attack vector while all others are open. And that would not solve my issue that some process within terminal wants to use AE.

Hopefully you will not close this ticket, let it marinate a bit.

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.

Yes and No.

No. It is an Electron project developed in VSCode. In development everything is watched, live reloaded, transported to console etc

• renderer process is webpacked with injections, babeled and devserved, React, hotreloads etc, so UI gets instant updates while developing. One VSCode terminal tab for that.
• main and preload process is webpacked, babeled with live rebuild on watch. Another VSCode terminal tab for that.
• Electron itself is run via electronmon (one of many packages that wraps npm run electron and restarts on changes) so that everything is streamlined, app autorestarts when changes in main and preload processes happen. Another VSCode terminal tab for that.
• electron main process child_process.spawns binaries that access stuff where al kinds of permissions are needed from OS. Even if I formulated those native binaries as node_gyps it would be just another abstraction layer, it does not matter how I get that native OS bridge within nodejs userland in the context of this ticket.
• I checked VSCode terminal doesn't allow/request permissions to access media devices #95062 Microphones, cameras. I someone wanted to code "the next Slack" or "multimedia app", assuming Electron is used, one would not be able to use all those npm runs within VSCode terminal.
• Personally for a long time for anything but low language projects my setup was - VSCode as text editor, while iTerm for all the npm script launching and observing. At some point I started also to use VSCode for some remote coding on SBCs via SSH - tried and got used to using VSCode terminal for all calls and console observation.
• Developing Electron project via VSCode is a recursion 😄 ... but IMHO it is a recursion that should be allowed. And multimedia rich apps (need access to media devices, screen etc) are not that exotic.

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.

[deepak1556]

Sorry for the delayed response, we had discussed this internally and decided to enable the following entitlements.

com.apple.security.automation.apple-events
com.apple.security.device.camera
com.apple.security.device.audio-input

[kroko]

Thank you! Apart from entitlements

• Allow AppleScript from terminal. references #119787 #119788 adds NSAppleEventsUsageDescription to Info.plist
• NSCameraUsageDescription and NSMicrophoneUsageDescription already are inherited by VSCode from Electron base.

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 (⚠) which should be safe.

FYI to reset permissions programmatically (which would allow VSCode to have a menu entry under Preferences or Help to disallow itself)

tccutil reset AppleEvents com.microsoft.VSCode
tccutil reset Camera com.microsoft.VSCode
tccutil reset Microphone com.microsoft.VSCode

or just

tccutil reset All com.microsoft.VSCode

full list (will differ based on os version)

Accessibility
AddressBook
All
AppleEvents
Calendar
Camera
ContactsFull
ContactsLimited
DeveloperTool
Facebook
FileProviderDomain
FileProviderPresence
LinkedIn
ListenEvent
Liverpool
Location
MediaLibrary
Microphone
Motion
Photos
PhotosAdd
PostEvent
Reminders
ScreenCapture
ShareKit
SinaWeibo
Siri
SpeechRecognition
SystemPolicyAllFiles
SystemPolicyDesktopFolder
SystemPolicyDeveloperFiles
SystemPolicyDocumentsFolder
SystemPolicyDownloadsFolder
SystemPolicyNetworkVolumes
SystemPolicyRemovableVolumes
SystemPolicySysAdminFiles
TencentWeibo
Twitter
Ubiquity
Willow

[deepak1556]

They could be reformulated though for uberclarity if one knows that VSCode itself will not use those features

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.

FYI to reset permissions programmatically (which would allow VSCode to have a menu entry under Preferences or Help to disallow itself)

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.