Support AppLocker

[FolBol]

=> done - not fixed, seems to be even worse, as VSCode does only show black Window when started as admin.

• VSCode Version: 1.52.0, Electron 9.3.5
• OS Version: 2004

Steps to Reproduce:

1. Activate AppLocker with Default Rules
2. Start VSCode elevated
3. Look at the AppLocker Logs - you will see 50/50 denied/allowed events: Good and normal: %OSDRIVE%\USERS\ADMIN\APPDATA\LOCAL\PROGRAMS\MICROSOFT VS CODE INSIDERS\CODE - INSIDERS.EXE was allowed to run. Bad: %OSDRIVE%\USERS\ADMIN\APPDATA\LOCAL\PROGRAMS\MICROSOFT VS CODE INSIDERS\CODE - INSIDERS.EXE was prevented from running.

Does this issue occur when all extensions are disabled?: Yes

Problem seems to be the way code.exe does launch itself on startup, using the API CreateProcessAsUserW() (50%) in a special way. (dwCreationFlags as per debug: 0x8040c + dwflags of startupinfo 0x180) But this seems not to be the only differnence as this is not causing an issue on a little test-program. The (and those are the allowed events) process creates which are done using API CreateProcessW() (50%) do not cause an issue.

[altonius]

@Chuxel, not sure if this is relevant but AppLocker blocking some instances of code.exe doesn't occur if the --no-sandbox flag is used when running as Admin. This issues may be similar to what the Chromium sandbox is also experiencing (https://bugs.chromium.org/p/chromium/issues/detail?id=740132)

[Chuxel]

@altonius Yes, but we wouldn't want to run this way by default unfortunately. While --no-sandbox might be a reasonable workaround in some cases, doing that does have a security impact. This only seems to occur when running as admin, which we generally do not recommend doing since this would also give anything you run rights to modify things like the contents of the Windows folder without your knowledge. VS Code has built-in escalation support for save operations that need to update files that require escalated administrator privileged files on an as-needed basis for this reason.

Under the hood, VS Code uses Electron which in turn uses Chromium so the problem is the same. I don't believe there's another resolution here since this seems very specific to running as admin with AppLocker like Chrome. We could in concept document it, but honestly this setup adds risk on its own.

Thoughts on documenting @kieferrm @chrisdias given risks?

[altonius]

I agree with you that we should not run vscode as Admin.

Any documentation that highlights this would be appreciated.

On Wed, 28 Apr 2021, 05:48 Chuck Lantz, @.***> wrote:

@altonius https://github.com/altonius Yes, but we wouldn't want to run this way by default unfortunately. While --no-sandbox might be a reasonable workaround in some cases, doing that does have a security impact. This only seems to occur when running as admin, which we generally do not recommend doing since this would also give anything you run rights to modify things like the contents of the Windows folder without your knowledge. VS Code has built-in escalation support save operations that need to updating files that require escalated administrator privileged files on an as-needed basis for this reason.

Under the hood, VS Code uses Electron which in turn uses Chromium so the problem is the same. I don't believe there's another resolution here since this seems very specific to running as admin with AppLocker like Chrome. We could in concept document it, but honestly this setup adds risk on its own.

Thoughts on documenting @kieferrm https://github.com/kieferrm @chrisdias https://github.com/chrisdias given risks?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/112538#issuecomment-827881495, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQ4QBHFGZ2NJWAMZ5AJWBDTK4IJDANCNFSM4U4AMD5A .

[Willisplayed]

Thanks alot really helpful you are