m2team / privexec Goto Github PK

Privexec.json style update
wsudo build command rewrite

Firefox and Chrome can't be started in AppContainer.

They are not executed despite the permissions I have given.

再次打扰了。
这次的目的还是为了降权。
想法是直接降低不行，那就做个完美的中介程序。

比如 Firefox.exe 改名，原文件名用中介程序顶替。
某管理员程序，掉用 Firefox 打开网站 abc.com.
中介程序 ，读取配置文件，改变 权限 启动 Firefox，打开 abc.com。中介程序退出。

Privexec 能做这样的改动吗？
当然搞个专门的小程序更好。

要求有些过分，抱歉。😅

I first want to thank you for sharing this project that makes it much easier to investigate AppContainer isolation on Windows! However, I am struggling to understand how to grant AppContainer capabilities like "removable media" ( WinCapabilityRemovableStorageSid), "internet client" (WinCapabilityInternetClientSid) and similar to my applications. Don't really understand why it doesn't work. See examples below.

I've already verified in Process Explorer that the enabled capabilities are correctly propagated to the security settings for the launched process. The problem therefore appear more fundamental somehow. Any clue about why this doesn't work?

Removable media example

Network access example

STATUS UPDATE: Client-side socket connections will actually be enabled if using the WinSock API directly.

Thank you for your great program.

The AppContainer launching works well and is successful, but I think that it can be improved by adding the ability to choose/select from a list of different AppContainer "Capabilities" to give more power and flexibility to your AppContainer launching functionality.

It would be good to have a button which brings up a dialog to choose different AppContainer "Capabilities".

Some example concepts:

Blog link: https://www.andrea-allievi.com/blog/first-week-of-june/

Relevant source code: https://github.com/AaLl86/retroware/tree/master/AppContainers

Image example (AppContainer Capabilities list: Select):

That "Select" button would bring up a multi-list of capabilities to choose from and select prior to launching an app within an AppContainer.

Thank you for your time.

WSUDO add -e --env KEY=VALUE or wsudo KEY=VALUE cmd style to set environment.

Now that the AppContainer functionality is working 100%, it would be great to have an option to run within LPAC sandbox as well. James Forshaw (Google Project Zero / Chrome sandbox) suggested to me that it is just one additional security attribute during launch to be low privilege AC.

This would require an additional item on the Privexec drop down menu and wsudo.

AppContainer
AppContainer (LPAC)
Mandatory Integrity Control
No Elevated (UAC)
Administrator

Attribute as shown from Process Hacker:

Code that verifies LPAC is enabled or not:
https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/blob/master/NtApiDotNet/NtToken.cs#L2583

This security attribute needs to be added during process launch and determines that AppContainer is Low Privilege AppContainer (LPAC) which is more secure in comparison to regular AC.

Therefore, having a choice between two types of AppContainer on menu would be excellent.

You already have LPAC capabilities, so that part of the development is already there. You just need the WIN://NOALLAPPPKG security attribute added to token during launch.

Thank you. Keep up the fantastic work!

Thank you for implementing that Color Change feature. Excellent work!

I have found two bugs related to this feature. One of the bugs, I have a fix for.

Bug 1: The "Enable LPAC" text beside the checkbox does not respect the color changing of the text. Therefore, for example, if you change the background to black, all of the text changes correctly to white but the "Enable LPAC" text stays black and therefore cannot be seen.

My Github is far out of sync and therefore I can't do a simple pull request right now. So I will have to do the code here.

Line 109: https://github.com/M2Team/Privexec/blob/master/Appexec/Appexec.rc#L109

Change:
CHECKBOX "Enable LPAC",IDC_LPACMODE,200,20,50,12, CS_BASE

To (fix):
CHECKBOX "",IDC_LPACMODE,200,20,10,11, CS_BASE
LTEXT "Enable Less Privileged AppContainer",IDS_APPCONTAINER_NAME,212,21,180,11

This simple code change fixes Bug 1 right away and looks great. I have compiled and tested locally.

There is one part of that code that "should" be fixed but I do not understand. I re-used "IDS_APPCONTAINER_NAME" as a temporary part of the fix. So I need for you to fix that part before adding the fix for Bug 1.

Bug 2: This bug is more complex and I do not know how to fix. If you change the background to black, all of the foreground text turns white and looks and works as expected. Excellent. However, when you close out of Appexec, and re-open Appexec, the blackground remains black which is good, but the text returns to black upon subsequent starts and therefore you cannot visually see any of the text at all.

Thank you for your time. Keep up the great work.

Wsudo 4.0.0-rc1 running in non-elevated process can't open GUI apps (e.g. serviwin.exe or autoruns64.exe) with -T or -S flag.

Examples:

1. In Windows Run Command Box (Windows Key + R), wsudo -T serviwin fails to launch serviwin

2. In non-elevated cmd, powershell, or pwsh console, wsudo -T serviwin fails with error message: 'current process not runing in administrator'

3. Attempting to launch a GUI app (e.g. serviwin.exe or autoruns64.exe) with -T or -S flag from context menu fails e.g. using the following registry entry (in inf file AddReg format) hkcr,*\shell\runasTI\command,,,wsudo -T """%V"""

Example 3 is especially unfortunate, since it seems to prevent wsudo from launching GUI apps (e.g. serviwin.exe or autoruns64.exe) with -T or -S flag from the context menu (i.e. right clicking on the GUI app).

It appears this issue is limited to GUI apps and flags -T and -S. Evidence:

a. Wsudo running in non-elevated process opens CUI apps (e.g. cmd.exe, powershell.exe, and pwsh.exe) with -T or -S flag without issue.

b. Wsudo running in non-elevated process opens GUI apps (e.g. serviwin.exe or autoruns64.exe) with -A or -U flag without issue.

OS details: Windows 10 x64 Enterprise version 2004 build 19041.572

Enable access some folder support. use GetNamedSecurityInfo SetEntriesInAcl SetNamedSecurityInfo

Fun with AppContainers: https://scorpiosoftware.net/2019/01/15/fun-with-appcontainers/

https://github.com/zodiacon/RunAppContainer

Modifying the ACLs of an Object in C++

#include <windows.h>
#include <stdio.h>

DWORD AddAceToObjectsSecurityDescriptor (
    LPTSTR pszObjName,          // name of object
    SE_OBJECT_TYPE ObjectType,  // type of object
    LPTSTR pszTrustee,          // trustee for new ACE
    TRUSTEE_FORM TrusteeForm,   // format of trustee structure
    DWORD dwAccessRights,       // access mask for new ACE
    ACCESS_MODE AccessMode,     // type of ACE
    DWORD dwInheritance         // inheritance flags for new ACE
) 
{
    DWORD dwRes = 0;
    PACL pOldDACL = NULL, pNewDACL = NULL;
    PSECURITY_DESCRIPTOR pSD = NULL;
    EXPLICIT_ACCESS ea;

    if (NULL == pszObjName) 
        return ERROR_INVALID_PARAMETER;

    // Get a pointer to the existing DACL.

    dwRes = GetNamedSecurityInfo(pszObjName, ObjectType, 
          DACL_SECURITY_INFORMATION,
          NULL, NULL, &pOldDACL, NULL, &pSD);
    if (ERROR_SUCCESS != dwRes) {
        printf( "GetNamedSecurityInfo Error %u\n", dwRes );
        goto Cleanup; 
    }  

    // Initialize an EXPLICIT_ACCESS structure for the new ACE. 

    ZeroMemory(&ea, sizeof(EXPLICIT_ACCESS));
    ea.grfAccessPermissions = dwAccessRights;
    ea.grfAccessMode = AccessMode;
    ea.grfInheritance= dwInheritance;
    ea.Trustee.TrusteeForm = TrusteeForm;
    ea.Trustee.ptstrName = pszTrustee;

    // Create a new ACL that merges the new ACE
    // into the existing DACL.

    dwRes = SetEntriesInAcl(1, &ea, pOldDACL, &pNewDACL);
    if (ERROR_SUCCESS != dwRes)  {
        printf( "SetEntriesInAcl Error %u\n", dwRes );
        goto Cleanup; 
    }  

    // Attach the new ACL as the object's DACL.

    dwRes = SetNamedSecurityInfo(pszObjName, ObjectType, 
          DACL_SECURITY_INFORMATION,
          NULL, NULL, pNewDACL, NULL);
    if (ERROR_SUCCESS != dwRes)  {
        printf( "SetNamedSecurityInfo Error %u\n", dwRes );
        goto Cleanup; 
    }  

    Cleanup:

        if(pSD != NULL) 
            LocalFree((HLOCAL) pSD); 
        if(pNewDACL != NULL) 
            LocalFree((HLOCAL) pNewDACL); 

        return dwRes;
}

TODO

like: PowerShell/PowerShell#9970

https://github.com/M2Team/Privexec/blob/master/Privexec.Core/AppContainers.cpp#L56

Lines 55-56 show:

Entry<WELL_KNOWN_SID_TYPE>(u8"videosLibrary", WinCapabilityPicturesLibrarySid),

Should be:

Entry<WELL_KNOWN_SID_TYPE>(u8"videosLibrary", WinCapabilityVideosLibrarySid),

Otherwise everything is working great for the latest AppContainer capabilities development.

Thank you.

System Informer (previously Process Hacker) has been keeping a more up-to-date list of capabilities and adds more quite frequently in comparison to the previous source.

Source: https://github.com/winsiderss/systeminformer/blob/master/SystemInformer/resources/capslist.txt

Is it possible to add this as a source of capabilities to consolidate the capabilities list in Privexec/AppExec?

Thanks!

How to elevate current process in script?

When using baulk to install wsudo, we need to save the configuration file to the specified directory correctly.

主要是想对一些程序永久性降权。

目前的方法都是通过，中介程序来实现降权，如果程序被直接掉用就不会被降权。
希望能实现：指定程序，被任何权限的程序掉用，都不会被提权。

比如 Notepad.exe 被设定为 Users 后， 具有 Administrators 权限的程序掉用它后，
Notepad.exe 任然以 Users 权限启动。

请问有这样的办法吗？

如题。观察到M2Team 下还有一个nsudo项目

TODO

• Provide Enable All Privileges.
• Current Process, Current User are missing.

Then it will be perfect.

Change "App Container" in UI to "AppContainer".

https://github.com/M2Team/Privexec/blob/master/Privexec/Privexec.rc#L115

Problem:

LTEXT "App Container Capabilities: ",IDC_COMMAND_SID,15,112,200,13

Fix:

LTEXT "AppContainer Capabilities: ",IDC_COMMAND_SID,15,112,200,13

https://github.com/M2Team/Privexec/blob/master/Privexec/main.cpp#L113

Problem:

users.push_back(std::make_pair(priv::ProcessAppContainer, L"App Container"));

Fix:

users.push_back(std::make_pair(priv::ProcessAppContainer, L"AppContainer"));

There are some minor English spelling or typo errors on lines 120-133:
(The spelling fixes required some minor spacing changes in the checkbox spacing. It was "Musics" to "Music" and "Remove Storages" to "Removable Storage". Since "Removable Storage" was longer text, it required a bunch of changes to the spacing numbers.

https://github.com/M2Team/Privexec/blob/master/Privexec/Privexec.rc#L120

Problem:

CHECKBOX    "Internet Client",IDP_INTERNETCLIENT,30,150,80,12, CS_BASE
CHECKBOX    "Private Network",IDP_PRIVATENETWORKCLIENTSERVER,110,150,65,12, CS_BASE
CHECKBOX    "Documents",IDP_DOCUMENTSLIBRARY,190,150,60,12, CS_BASE
CHECKBOX    "Internet Client Server",IDP_INTERNETCLIENTSERVER,270,150,90,12, CS_BASE

CHECKBOX    "Pictures",IDP_PICTURESLIBRARY,30,166,80,12, CS_BASE
CHECKBOX    "Videos",IDP_VIDEOSLIBRARY,110,166,80,12, CS_BASE
CHECKBOX    "Musics",IDP_MUSICLIBRARY,190,166,40,12, CS_BASE
CHECKBOX    "Enterprise Authentication",IDP_ENTERPRISEAUTHENTICATION,270,166,110,12, CS_BASE

CHECKBOX    "Remove Storages",IDP_REMOVABLESTORAGE,30,180,70,12, CS_BASE
CHECKBOX    "Appointments",IDP_APPOINTMENTS,110,180,70,12, CS_BASE
CHECKBOX    "Contacts",IDP_CONTACTS,190,180,70,12, CS_BASE
CHECKBOX    "Shared User Certificates",IDP_SHAREDUSERCERTIFICATES,270,180,110,12, CS_BASE

Fix:

CHECKBOX    "Internet Client",IDP_INTERNETCLIENT,30,150,80,12, CS_BASE
CHECKBOX    "Private Network",IDP_PRIVATENETWORKCLIENTSERVER,115,150,65,12, CS_BASE
CHECKBOX    "Documents",IDP_DOCUMENTSLIBRARY,195,150,60,12, CS_BASE
CHECKBOX    "Internet Client Server",IDP_INTERNETCLIENTSERVER,270,150,90,12, CS_BASE

CHECKBOX    "Pictures",IDP_PICTURESLIBRARY,30,166,80,12, CS_BASE
CHECKBOX    "Videos",IDP_VIDEOSLIBRARY,115,166,80,12, CS_BASE
CHECKBOX    "Music",IDP_MUSICLIBRARY,195,166,40,12, CS_BASE
CHECKBOX    "Enterprise Authentication",IDP_ENTERPRISEAUTHENTICATION,270,166,110,12, CS_BASE

CHECKBOX    "Removable Storage",IDP_REMOVABLESTORAGE,30,180,80,12, CS_BASE
CHECKBOX    "Appointments",IDP_APPOINTMENTS,115,180,70,12, CS_BASE
CHECKBOX    "Contacts",IDP_CONTACTS,195,180,70,12, CS_BASE
CHECKBOX    "Shared User Certificates",IDP_SHAREDUSERCERTIFICATES,270,180,110,12, CS_BASE

When running wsudo from a "High Integrity" account where Admin Approval Mode is disabled via policy, eg the pre-existing super "Administrator" account falls in this category by default, attempting to launch a program via "wsudo -u NoElevated" (attempting to make it run as Medium Integrity) still results in the process being launched as High Integrity instead though "wsudo -u MIC" properly launches the program as Low Integrity. Currently I can not get anything to work simply launching it as Medium Integrity as expected in this scenario. Tested with wsudo 2.5.0.248

Really hope I didn't just miss something in the documentation... Thanks for this great software along with NSudo!

I think it is better than using the Task Scheduler or search the explorer.exe process token.

How to:

1. Get the current session's winlogon.exe process token and duplicate its returned token.
2. Enable SE_TCB_NAME privilege on the duplicated token.
3. Get the current process's Session ID. (Reason: https://forums.mydigitallife.net/threads/nsudo-a-powerful-system-administration-tool.59268/page-7#post-1348433 )
4. Call WTSQueryUserToken and duplicate its returned token.

For more information, you can read the source code of the NSudo project.

Mouri.

我是Windows 10
操作系统自带的软件都正常，但是有的软件就是不行，但是这些软件直接双击运行没有问题。
请问这是什么原因导致的？要如何解决？

Feature Request for wsudo:

wsudo has everything from Appx manifest import, capability parsing and LPAC but the only thing that wsudo is missing from Privexec/AppExec is the ability to choose AppContainer Name which then allows random SID generated based on unique AppContainer Name.

It would be great if wsudo can borrow this feature/code from AppExec codebase. I don't know if this would be easy or difficult to add this to wsudo.

I usually begin my AppContainer testing with AppExec GUI. After everything works well, I like to use wsudo to create shortcuts on the taskbar or Start menu that starts specific programs within LPAC sandbox with wsudo commands in the shortcuts.

I have been using Less Privileged AppContainer (LPAC) sandbox successfully with Mozilla Thunderbird, Notepad++, Explorer++ and a few other programs. I use a different Appx Manifest file for each program with different capabilities. The only problem is that they are all using the same AppContainer SID with wsudo and therefore being able to choose AppContainer Name and different SID would be great.

Thank you for your time.

I spent some time doing some simple GUI restructuring within the AppExec.rc file locally on my machine and have compiled and using the example currently.

• more horizontal space for Folder and Registry ACLs which often can be long
• more vertical space for App Capabilities List for easier navigation and selection
• removed Alias from Command box because Alias' are not very relevant to AppContainer *

(*) You will likely need to make some changes to the Alias code in AppExec because I removed it from AppExec.rc file in a more "hacky" type of way.

Anyway, please let me know what you think. I am always happy to share any changes that I have made. I can send you the code snippet from AppExec.rc file or send you compiled AppExec.exe to play around with so that you can test and see if you like the changes.

Hide Window support

wsudo -w -H notepad.exe does not work.

I'm not sure if this is really an issue with Privexec but I figured if anybody had any clue what was going on here it'd be @WildByDesign @fcharlie or @forderud

I'm trying to write a PowerShell script that can use the Windows.Networking.BackgroundTransfer.BackgroundDownloader class from WinRT.

However, this class appear to only be accessible from within an App Container

If you run the following code from a normal PowerShell window

[Windows.Networking.BackgroundTransfer, Windows.Networking.BackgroundTransfer.BackgroundDownloader, ContentType=WindowsRuntime] | Out-Null
[Windows.Networking.BackgroundTransfer.BackgroundDownloader]::new() 

you get

Exception calling ".ctor" with "0" argument(s): "This operation is only valid in the context of an app container. (Exception from 
HRESULT: 0x8007109A)"
At C:\Users\DKattan\Immense Networks\Immense Networks Intranet - Powershell Scripts\Test-DeliveryOptimizationMinimal.ps1:2 char:1   
+ [Windows.Networking.BackgroundTransfer.BackgroundDownloader]::new()
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : Exception

If I use Privexec to spawn Powershell it constructs the object

FailureToastNotification : 
SuccessTileNotification  : 
SuccessToastNotification : 
TransferGroup            : 
FailureTileNotification  : 
CompletionGroup          : 
CostPolicy               : Default
Group                    : 
Method                   : 
ProxyCredential          : 
ServerCredential         : 

Naturally the next thing I need to do is give the class I constructed a Windows.Storage.StorageFile object that points to the download destination.

I do this with the following code, which works as expected from within normal PowerShell

Add-Type -AssemblyName System.Runtime.WindowsRuntime
[Windows.Storage.StorageFile,Windows.Storage,ContentType=WindowsRuntime] | Out-Null
$asTaskGeneric = ([System.WindowsRuntimeSystemExtensions].GetMethods() | ? { $_.Name -eq 'AsTask' -and $_.GetParameters().Count -eq 1 -and $_.GetParameters()[0].ParameterType.Name -eq 'IAsyncOperation`1' })[0]
Function Await($WinRtTask, $ResultType) {
    $asTask = $asTaskGeneric.MakeGenericMethod($ResultType)
    $netTask = $asTask.Invoke($null, @($WinRtTask))
    try
    {
        $netTask.Wait(-1)
    }
    catch
    {
        Write-Error ($_.Exception.InnerException.InnerException)
    }
    $netTask.Result
}
Await ([Windows.Storage.StorageFile]::GetFileFromPathAsync("C:\temp\test.ps1")) ([Windows.Storage.StorageFile])

However, it seems like no matter what path I specify or what capabilities I give the App Container, I always get

Await : System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
At line:17 char:1
+ Await ([Windows.Storage.StorageFile]::GetFileFromPathAsync("C:\temp\t ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Await

Things I've tried:

• Pre-Creating the file
• Giving the AppContainer broadFileSystemAccess
• Putting the destination inside of the AppContainer's AppData
• Putting the destination inside of the User's profile
• Running icacls "C:\temp\test.txt" /grant *S-1-15-2-1:(OI)(CI)(F) /T && icacls "C:\temp\test.txt" /grant *S-1-15-2-2:(OI)(CI)(F) /T

When I run Procmon, no activity is generated when it fails in the AppContainer.

I know Procmon is working because I see lots of activity when I run the same code in normal PowerShell.

My speculation is that this is one of the WinRT APIs that requires an Appx package manifest in addition to being run in an App Container. However I find it odd that the code works fine outside of an AppContainer.

I'm hoping there's something obvious I'm missing.

At the moment, it is not possible to add AppContainer Capabilities aside from the main Well Known SID types. In a previous issue, we had discussed this and realized that it needs more time to figure out and more development in that regard.

For right now, it would be a nice feature if we could manually add some Capability SIDs. Possibly in the user interface, maybe have another button in which we can add a list of other Capability SIDs and type/copy those SIDs in manually.

For example, I figured out a way to determine Capability SIDs by using @tyranid 's Token Viewer program from https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools repo combined with some command line flags for Chromium browser.

Some Capability SIDs that I have discovered thus far are:

broadFileSystemAccess
S-1-15-3-1024-3247244612-4072385457-573406302-3159362907-4108726569-214783218-394353107-2658650418
internetExplorer
S-1-15-3-1024-3074157858-2547534938-2297668728-3066639066-623563824-3135784797-1864023905-3488129466
constrainedImpersonation
S-1-15-3-1024-1604681682-535129537-3273749797-3666938095-336295784-2177615760-2743807136-2867270584
runFullTrust
S-1-15-3-1024-1365790099-2797813016-1714917928-519942599-2377126242-1094757716-3949770552-3596009590
registryRead*
S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681
lpacAppExperience
S-1-15-3-1024-1502825166-1963708345-2616377461-2562897074-4192028372-3968301570-1997628692-1435953622

But of course there are many more. Therefore, if we had an option in the user interface to manually add Capability SIDs that would be very handy for the time being.

Issue:
Both Privexec and AppExec fail to execute programs from directories that contain spaces. Example: C:\Program Files\Windows NT\Accessories\wordpad.exe

Error:

Privexec SplitArgv failed
command not found 'C:\Program'

Workaround:
If I manually add quotation marks around C:\Program Files\Windows NT\Accessories\wordpad.exe, such as "C:\Program Files\Windows NT\Accessories\wordpad.exe" then Privexec and AppExec can successfully execute programs from directories that contain spaces.

I just noticed that registry ACLs are currently not working in AppExec. File system ACLs are working.

All examples below failed to set ACL:

Computer\HKEY_CURRENT_USER\SOFTWARE\Sysinternals
HKEY_CURRENT_USER\SOFTWARE\Sysinternals
CURRENT_USER\SOFTWARE\Sysinternals
HKCU\SOFTWARE\Sysinternals

Running AppExec as admin also failed to set registry ACL.

However, in the registry ACL reference app, RunAppContainer (https://github.com/zodiacon/RunAppContainer / https://scorpiosoftware.net/2019/01/15/fun-with-appcontainers/) I was able to successfully use: CURRENT_USER\SOFTWARE\Sysinternals

I haven't used registry ACLs in AppExec for a long time now and therefore I don't recall if it worked initially or if it stopped working at some point in time.

Add Start Directory support

Report Error: Elavator::impersonation_system_token<OpenProcessToken> 句柄无效。

Privexec and Appexec are working great for some time now. Excellent work.

The majority of App Capabilities are working as expected. However, some of the more powerful Restricted Capabilities (rescap) are not working because something is missing. As we know, the Restricted Capabilities are showing in the Token Properties. So that is good. The rescap capabilities are in place in the token correctly. But something is missing as part of their xml configuration to unlock them within the system.

There are a few projects on Github, file explorer type uwp programs, which are great code examples for showing how this is working since they all use this technique.

Files-UWP is one example: https://github.com/duke7553/files-uwp

Microsoft Doc: https://docs.microsoft.com/en-us/windows/uwp/files/file-access-permissions

See the Example from the very bottom of that documentation page:

Example

This example adds the restricted broadFileSystemAccess capability. In addition to specifying the capability, the rescap namespace must be added, and is also added to IgnorableNamespaces:

<Package
  ...
  xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
  IgnorableNamespaces="uap mp uap5 rescap">
...
<Capabilities>
    <rescap:Capability Name="broadFileSystemAccess" />
</Capabilities>

Those two lines ( xmlns:rescap= and IgnorableNamespaces= ) are key important lines.

From the Files-UWP project, you can see the line within Package section:
https://github.com/duke7553/files-uwp/blob/master/FilesUwp.Package/Package.appxmanifest#L2

Now, I don't know how we can get those two lines of xml config ( xmlns:rescap= and IgnorableNamespaces= ) into the target process. That would make the system aware that these apps are requesting those privileges. I don't know if this can work from a "process launcher" perspective or not. If you can get this working, AppExec and wsudo would gain significant power.

Thank you for your time.

Improve cmake to generate version information

已 %APPDATA% 为例，不少软件会默认在此写入文件，--env 参数能改变，目标程序对于这个目录的识别吗？
如果可行，该如何写。
我自己测试了，下面两种写法，是无效的。

wsudo.exe  --env   "APPDATA=D:\aaa"   firefox.exe
wsudo.exe  --env   "%APPDATA%=D:\aaa"   firefox.exe