Skip to content
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

AppContainer for Win32 apps #219

Open
sylveon opened this issue Oct 1, 2020 · 52 comments
Open

AppContainer for Win32 apps #219

sylveon opened this issue Oct 1, 2020 · 52 comments
Assignees
Labels
area-AppContainer area-Win32 Support for Win32 packaged and non-packaged apps feature

Comments

@sylveon
Copy link

sylveon commented Oct 1, 2020

Proposal: AppContainer for Win32 apps

Summary

This proposal attempts to bring the advantages of app containers (limited permissions and file system access) to Win32, by documenting how a packaged Win32 app can be hosted in one, and allowing Win32-only APIs which are not currently allowed to be called from an AppContainer.

Currently, this can be achieved by using EntryPoint="Windows.PartialTrustApplication" in the appx manifest. By setting this, your Win32 app is launched in the AppContainer:

image

But, this entry point is largely undocumented (its only reference on the entire internet is an electron PR), and some things are broken.

For example, tray icons (with ShellNotifyIcon) are simply not working, and return an access denied error.

OpenProcess, even with only the PROCESS_QUERY_LIMITED_INFORMATION permission, also returns an access denied. This permission is mostly harmless and only allows a very limited subset of APIs, none of which can do anything harmful to the process. There is little to zero security implication in allowing this.

As the screenshot above shows, I've tried doing this with my own app, and these are the two big limitations I've encountered (as well as the general lack of documentation around this topic).

Rationale

  • This makes Win32 apps safer for everyone. Long gone are programming mistakes or bugs that would accidentally wipe your whole drive.
  • Allows to host Win32 apps in Windows 10X natively, without the need for virtualization. Since Win32 apps in AppContainers are under the same restriction than UWP apps, there is no need to use an expensive virtualization stack to run them, but instead a thin compatibility layer (if any). By doing this, it makes Win32 apps faster and more energy efficient under 10X.
  • Allows developers to ship Win32 apps to the Microsoft Store without requesting access to the runFullTrust restricted capability
    • This would allow to make sandboxing more fine-grained rather than all or nothing, for example a specific restricted capability to enable more process access permissions under the sandbox.
    • It can also bring the possibility to lockdown runFullTrust to apps that actually do need to run completely outside the container for legitimate reasons, rather than every Win32 app.

Scope

Capability Priority
This proposal will allow developers to host Win32 apps in the AppContainer with ease Must
This proposal will allow developers to use tray icons from within an AppContainer Must
This proposal will allow developers to call Win32-only APIs which are not security risks from within the AppContainer Must
This proposal will allow developers to use a full trust helper along their partial trust Win32 app Should
This proposal will introduce new restricted capabilities that would allow some normally restricted API calls to work Could
This proposal will bring UWP privacy controls to packaged Win32 apps Could
This proposal will allow developers to completely escape the AppContainer Won't

Important Notes

My app uses, along the things mentioned prior:

  • SetWindowsHookEx to inject Windows Explorer (this is required for core functionality to work correctly)
  • PROCESS_VM_OPERATION, to be able to inject a payload that the hooked DLL can read for contextual information (related: SetWinEventHook and SetWindowsHookEx does not provide a way to pass user data Windows-Dev-Performance#28)
  • SetWinEventHook to know changes that happen to the window layout (opened, moved, maximized, minimized, closed, etc).
  • SendMessage, to be able to trigger a refresh of the taskbar's theme in Windows Explorer.

While SetWinEventHook seems to already work today in the AppContainer (hooray), other APIs mentioned would need to be moved to a full trust helper. If this proposal where to come to fruition, I would be one of the first to jump unboard and move that functionality to a helper process.

This is part of the reason I suggested to introduce new restricted capabilities which would unblock some APIs, as simply unlocking specific APIs under request is far safer and simpler than making a full trust helper process.

Open Questions

Would it be beneficial for anybody to introduce a partial trust equivalent to FullTrustProcessLauncher?

@sylveon
Copy link
Author

sylveon commented Oct 1, 2020

Oh yeah, forgot to mention: you can't build an appx using PartialTrustApplication without adding mp:PhoneIdentity. That requirement should go away, as it's not relevant anymore.

@Felix-Dev
Copy link

Felix-Dev commented Oct 1, 2020

I would like to add here that running a simple "Hello World" .NET Core 3.1 WPF app in the AppContainer utilizes around 20% of my CPU whereas running the exact same app without the AppContainer uses ~0% of the CPU (per Task Manager). Which makes using the AppContainer for this very basic Hello World WPF app rather impractical for now (other than being a cool experiment).

It runs fine (~0%) for a WinUI 3.0 Preview 2 C++ Desktop app.

@sylveon
Copy link
Author

sylveon commented Oct 1, 2020

This issue doesn't reproduce with a C++ app, and as long as the app doesn't try to do things which AppContainer disallows, actually works without problem. This might be a bug with .NET where some API call is denied by the sandbox, and it keeps retrying.

@77376
Copy link

77376 commented Oct 1, 2020

I would like to add :

Scope

Capability Priority
This proposal will allow UWP's Share target support for win32 apps running in AppContainer Must
This proposal will allow UWP's privacy oriented contract based permission system support for win32 apps running in AppContainer Must
This proposal will make win32 apps running in AppContainer be a Universal app essentially allow running on other windows platforms Must
This proposal will by default force win32 apps to be a Low-IL app but can be Medium/High-IL level app through special user prompt only desktop Should

Open Questions/Rationale:

Why would anyone want to run win32 apps in other platforms?

the main point is , it is not feasible/sustainable to rewrite my app from scratch just to run it on other platforms. also user adoption remains to be seen.

Please , let us have just one App Technology which is both modern+privacy oriented and at the same time powerful when needed.

aren't all win32 apps evil?
because appContainer manages user privacy and forces it to be a Low-IL app on other platforms , so it is as safe as anyother regular CoreWindow UWP app.

@sylveon
Copy link
Author

sylveon commented Oct 1, 2020

I disagree, my feature request is purely about the sandboxing. Things like share targets, or running on other platforms, should be different feature requests.

Privacy controls are already a could, and would be nice, but I do not consider them to be complete blockers.

AppContainer implies low IL and by design you can't elevate your IL (huge source of security vulnerabilities to allow escalation). If you need higher IL, use a full trust process or helper.

@77376
Copy link

77376 commented Oct 1, 2020

AppContainer implies low IL and by design you can't elevate your IL (huge source of security vulnerabilities to allow escalation). If you need higher IL, use a full trust process or helper.

we are here for changes, right ?

@sylveon
Copy link
Author

sylveon commented Oct 1, 2020

Yes but I'm not here to introduce security vulnerabilities, changes to how AppContainer works or ways to escape from it. Allowing low IL apps to elevate to medium or even high IL is all 3 at the same time.

@77376
Copy link

77376 commented Oct 1, 2020

Yes but I'm not here to introduce security vulnerabilities, changes to how AppContainer works or ways to escape from it. Allowing low IL apps to elevate to medium or even high IL is all 3 at the same time.

you say security vulnerabilities ? well, you are never truly secure on desktop and this is only asking through special user prompt only on desktop ):

@sylveon
Copy link
Author

sylveon commented Oct 1, 2020

Just giving the possibility for it to happen opens for potential vulnerabilities. If you're suggesting something like UAC, you'll be glad to learn it had multiple vulnerabilities in the past that allows apps to bypass the prompt and get elevated silently.

@77376
Copy link

77376 commented Oct 1, 2020

Just giving the possibility for it to happen opens for potential vulnerabilities. If you're suggesting something like UAC, you'll be glad to learn it had multiple vulnerabilities in the past that allows apps to bypass the prompt and get elevated silently.

"getting elevation silently" should not work inside AppContainer. so no

@sylveon
Copy link
Author

sylveon commented Oct 1, 2020

UAC was not supposed to allow that, but it did because of security vulnerabilities. Get my point? This will eventually repeat with a mechanism to elevate IL. I am strongly opposed to the idea.

Full trust processes already have medium IL, so if you need medium IL, use those. They're safer since you are limited to only executables declared in your package as full trust, not any arbitrary exe in your package. If you want a mechanism for users to consent to launching a full trust process, open another issue for that.

@77376
Copy link

77376 commented Oct 1, 2020

UAC was not supposed to allow that, but it did because of security vulnerabilities. Get my point? This will eventually repeat with a mechanism to elevate IL. I am strongly opposed to the idea.

so you are basically assuming , like win32 had secure vulnerabilities AppContainer for win32 apps technology will have that too, without MS letting implement that in the first place (if they want).
Please let MS implement that first.

Full trust processes already have medium IL, so if you need medium IL, use those. They're safer since you are limited to only executables declared in your package as full trust, not any arbitrary exe in your package. If you want a mechanism for users to consent to launching a full trust process, open another issue for that.

this is an ask for win32 apps

@sylveon
Copy link
Author

sylveon commented Oct 1, 2020

Yes, we are humans and make mistakes. Keep the AppContainer at low IL, and if you want higher IL, run outside the AppContainer.

@stevewri stevewri added area-AppContainer area-Win32 Support for Win32 packaged and non-packaged apps labels Oct 1, 2020
@stevewri stevewri self-assigned this Oct 1, 2020
@ptorr-msft
Copy link
Contributor

windows.partialTrustProcess isn't well-documented precisely because it isn't well-supported :-). There are some niche scenarios where it can work, but by and large it won't work for most scenarios (as you have found). Come to think of it, we don't even document windows.fullTrustProcess in the manifest schema for some reason.

AppContainer is Low IL by definition. You can't "elevate" an AppContainer to Medium IL; then you're not in an AppContainer anymore. What I think we "should" support (opinion incoming, not a product plan) is the ability to launch the exact same app either in an AppContainer or not in an AppContainer, based on developer requests / user consent. So just like you can run a Win32 app at Medium IL most of the time and occasionally run it at High (elevated), so too should you be able to run an app at Low IL most of the time and occasionally run it at Medium (or High) if you need to. But then it's not in an AppContainer any more :-).

(FWIW The reason Shell_NotifyIcon doesn't work is that it is implemented by sending messages to the shell, but the shell is running at Medium IL and hence the messages are blocked from your Low IL process. It's a simple matter of programming to turn this into a brokered call, but that's why it doesn't work today.)

@Felix-Dev
Copy link

@ptorr-msft Am I reading your reply correctly in the sense that I shouldn't expect anytime soon (say till summer next year) a fix to ship which addresses the high CPU utilization for .NET Core (.NET Framework presumably too) Win32 apps running in an AppContainer?

What I think we "should" support (opinion incoming, not a product plan) is the ability to launch the exact same app either in an AppContainer or not in an AppContainer, based on developer requests / user consent.

Yes, please! It would be great if the AppContainer will become greatly supported for Win32 apps (better VS support, documentation,...). If I as a Win32 developer could use UWP XAML (WinUI 3) + APPX (MSIX) + AppContainer for my Win32 apps, then this would be very nice indeed. We are already getting the former two so if AppContainer could follow, that would be very cool 🙂

@sylveon
Copy link
Author

sylveon commented Oct 1, 2020

Thanks for the IL clarification.

I always strive to improve the security of my program, so when I stumbled upon the aforementioned Electron PR, my interest was piqued. After trying it and finding out that a lot of things don't work, I opened this issue in an attempt to make this more supported, for example by documenting what would work and what wouldn't.

My idea was to run the entire GUI and program logic in a low IL/partial trust process, and broker the "bad" stuff (that most people don't need, SetWindowsHookEx is very much a niche) in a medium IL/full trust process.

Since Shell_NotifyIcon would need to be brokered I could certainly implement my own brokering for it in that full trust process, but obviously the OS/Project Reunion doing it for the developer would be much better (and more secure than everybody rolling their own).

What I think we "should" support (opinion incoming, not a product plan) is the ability to launch the exact same app either in an AppContainer or not in an AppContainer, based on developer requests / user consent.

I also think that developers should be able to limit their apps to low IL only (effectively what partial trust does today)

@Felix-Dev I wouldn't expect a fix until that scenario is properly supported.

@77376
Copy link

77376 commented Oct 2, 2020

What I think we "should" support (opinion incoming, not a product plan) is the ability to launch the exact same app either in an AppContainer or not in an AppContainer, based on developer requests / user consent.

Yes,Please!

@DrusTheAxe
Copy link
Member

DrusTheAxe commented Oct 4, 2020

@ptorr-msft

AppContainer is Low IL by definition

Yes. Technically AppContainer is a property parallel to IntegrityLevel, but it's only possible to be an AppContainer today if IL=Low (that's why most folks think of it as Elevated > MediumIL > LowIL > AppContainer, even though technically incorrect). AppContainer+MediumIL doesn't exist today, and it's an oxymoron (MediumIL...but sandboxed?!?! Must be some kind of quantum computing thing Schroedinger's Cat is programming... :P)

@Felix-Dev we're keenly interested to learn of APIs folks are interested in that don't work in an AppContainer. Enabling more secure apps is a worthy goal but Windows is, as you might guess, pretty huge so feedback to help us know where to focus our efforts is invaluable.

Most of the proposed 'Scope' are very broad and difficult to be actionable, but this is a good thread to discuss the issue and spin off more focused proposals for follow up. To that end:

use tray icons

Use in what way? Are the specific tray icon (or merely tray or icon) APIs or behavior you find aren't accessible in an AppContainer? More details would help understand the gap and shape of work involved to solve it. This sounds like a good candidate to spin off to a separate dedicated issue e.g. "Enable Tray Icon X Y Z in a Windows.PartialTrustApplication"

use a full trust helper along their partial trust Win32 app

What sort of 'helper' are you thinking? Can you accomplish your goals if you define 2 applications in your package (PartialTrust 'app' + FullTrust 'helper')?

SendMessage, to be able to trigger a refresh of the taskbar's theme in Windows Explorer

Do you have a code snippet? Is there more taskbar functionality you'd like to use but found blocked by AppContainer?

OpenProcess, even with only the PROCESS_QUERY_LIMITED_INFORMATION permission, also returns an access denied. This permission is mostly harmless and only allows a very limited subset of APIs, none of which can do anything harmful to the process. There is little to zero security implication in allowing this.

That's not quite true. Even if you can't do anything to the process, reading data (w/o authorization) is very much a security concern. It's a little unclear what specifically you're trying to accomplish here. Could you elaborate?

If I as a Win32 developer could use UWP XAML (WinUI 3) + APPX (MSIX) + AppContainer for my Win32 apps, then this would be very nice indeed. We are already getting the former two so if AppContainer could follow, that would be very cool

AppContainer's availabile via Windows.PartialTrustApplication, albeit with limitations. Some of those are by design, but just some. But it's hard to assess in the abstract. Specifics are much more actionable.

P.S. Thanks for reporting the documentation gap. I've filed Microsoft-internal task 29686473 to address that.

@sylveon
Copy link
Author

sylveon commented Oct 4, 2020

Use in what way? Are the specific tray icon (or merely tray or icon) APIs or behavior you find aren't accessible in an AppContainer? More details would help understand the gap and shape of work involved to solve it. This sounds like a good candidate to spin off to a separate dedicated issue e.g. "Enable Tray Icon X Y Z in a Windows.PartialTrustApplication"

Today, Shell_NotifyIcon (which is the entry point for everything related to the notification area/tray icon) returns access denied for all calls when used from within AppContainer. So the gap is "none of it works". Enabling minimum functionality like being able to actually show a tray icon, send notifications (sure, the winrt API works in that case, but the win32 API is more accessible than the winrt API is), showing a tooltip and reacting to user clicks on the tray icon is crucial.

I didn't open an issue specifically for that because I wanted to test the waters. No point in complaining about a specific API not working if the entire scenario was not something you'd want to support.

For the rest of your comments:

The app I'm mentioning here is TranslucentTB. It alters the appearance of the system taskbar by calling the undocumented SetWindowCompositionAttribute API using the taskbar's handle. The API doesn't work in AppContainer and that's totally fine.

It offers the ability to have a different appearances depending on conditions (for example, when a window is maximized or the start menu is open). But since this kind of detection tends to not be 100% reliable, we offer a way to exclude some windows from this matching by class name, window title, or process name. We use PROCESS_QUERY_LIMITED_INFORMATION to get the process name with QueryFullProcessImageName to check against the blacklist, and don't store it. Currently in AppContainer this is broken. Maybe make this a capability?

One of the "states" you can get is to restore the taskbar to its normal appearance. The most reliable way I've found to get that is to do SendMessage(hwndTaskbar, WM_THEMECHANGED, 0, 0). This doesn't work in AppContainer and shouldn't.

Even if a lot that we do is questionable and has no place in AppContainer, I still see the value in AppContainer. I would like to run my GUI and most of the logic in AppContainer, and use a full trust process to broker operations not allowed by AppContainer. This way, I can reduce the possibility for accidental mistakes that could delete user data, and minimise the attack surface of my program (a bug in my logic wouldn't allow some other low IL application to go ham and elevate itself).

The full trust helper's primary purpose would be managing the hooking of Windows Explorer, calling SetWindowCompositionAttribute on the taskbar handle, and sending WM_THEMECHANGED.

@ptorr-msft
Copy link
Contributor

@sylveon modulo the use of undocumented APIs (which we do not condone / support), that kind of app structure (low-privileged UI process driving a higher-privileged "do the real work" process) is good. And I assume your current UI is Electron-based?

Given that you would need to rearchitect your app somewhat anyway (into the two different processes), is it feasible for you to move to a WebView inside a normal UWP app?

@sylveon
Copy link
Author

sylveon commented Oct 6, 2020

TranslucentTB is written using C++, so does not use Electron but rather a very basic GDI GUI.

My in-development version is using XAML Islands, for a couple of reasons:

  • Nice XAML GUI without the need for brokering everything between the UI and logic: UWP does not provide me all APIs I need to implement program logic, so I would need to broker those APIs or split GUI/logic code in two different processes.
  • Increased flexibility over just UWP: I can implement things like a window picker (similar to Spy++'s) with XAML Islands.
  • Background execution: the app needs to run 24/7, so has a tray icon and UWP background task limitations are not suitable (although that wouldn't be an issue if the logic is implemented in the full trust process).

AppContainer for Win32 would minimize the amount of rearchitecting/rewriting I have to do here, only brokering the few APIs that don't work (rather than like half of User32), while keeping the logic in the main low trust executable.

@ptorr-msft
Copy link
Contributor

As @riverar mentions above, packaging is moot here -- full-trust MSIX is not considered a security boundary since its primary purpose is to let developers opt-in to better behaviour (like clean uninstall) while maintaining high compatibility. There is some "light" virtualization applied to user files and registry state to help with the clean uninstall, but it is trivially defeated (whether maliciously or otherwise). For example if your app calls CreateProcess("cmd.exe") then CMD runs outside of your virtualized container to ensure it runs correctly.

We are interested in better security and privacy controls for "Win32 apps" (Medium IL processes) but it's not a simple problem to solve. It's good to hear the community's thoughts on this matter though, so please keep it coming. If / when we have more to share, we will do so.

@ysc3839
Copy link

ysc3839 commented Sep 2, 2021

Allows to host Win32 apps in Windows 10X natively

Although Win10X was cancellled, I want to say: IIRC user32.dll and most APIs in gdi32.dll was removed in Win10X, so traditional Win32 apps can't be run in Win10X.

@sylveon
Copy link
Author

sylveon commented Sep 2, 2021

Edge runs unsandboxed and unvirtualized on 10X, carrying its own copy of user32.dll around. This could be done for other Win32 apps running on 10X as well. This point is moot anyways now since 10X is on indefinite hiatus currently.

@JaiganeshKumaran
Copy link
Contributor

@ysc3839 traditional desktop apps can run on Windows 10x. It was an artificial limitation although I think they removed most of the legacy stuff needed to run some of them.

@WildByDesign
Copy link

WildByDesign commented Sep 12, 2021

Regarding the future of AppContainer for Win32 apps:

  • How much of a role does the new permissiveLearningMode capability in Windows 11 (and Windows Server 2022) play into instrumenting more legacy Win32 apps for AppContainer?

Also, the detailed ETW tracing ability for permissiveLearningMode is quite interesting.
(See: https://www.tiraniddo.dev/2021/09/lowbox-token-permissive-learning-mode.html)

This ETW tracing helps tremendously with determining which access checks would fail within the AppContainer sandbox and can assist in determining other capabilities a Win32 app may need to apply. Adding more specific capabilities narrows down the logging and therefore helps getting to the root of specific problems.

On a side note, I use SilkETW and SilkService (https://github.com/fireeye/SilkETW) to log all of these Permissive Learning Mode access checks to a JSON file. Whether you use the ETW trace logging such as in the blog link above or something else such as SilkETW, that logging can be quite massive.

  • Does Microsoft have any development plans for Permissive Learning Mode to better parse that ETW logging into quicker and easier ways to visually identify which parts of the access checks are failing in the AppContainer and suggest which capabilities to apply?

This is a positive advancement for Win32 apps in AppContainer on Windows 11 and Windows Server 2022.

I currently run the latest stable version of Firefox, Thunderbird, KeePass, Process Explorer, ProcDump, Notepad++, and more all within AppContainer sandboxes. Specifically, LPAC (Less Privileged AppContainer) for all of those processes. So this is exciting news for me and will be beneficial going forward.

One day I would like to write a blog to detail how to run the latest Firefox and KeePass within LPAC sandbox for more secure password management.

@sylveon
Copy link
Author

sylveon commented Sep 12, 2021

Interesting read, thanks! In my case I just ran my app with the partial trust capability and my logging was complete enough to identify the parts which didn't work. It would be nice if we could do something like partial trust + whatever token permissions we need to run directly in the app manifest.

Also curious at this quote, albeit off topic for this issue

Now you need to generate some log events. You just need to add the permissiveLearningMode capability when creating the lowbox token or process. You can almost certainly add it to your application's manifest as well when developing a sandboxed UWP application, but we'll assume here that we're setting up the sandbox manually.

Would this mean that theorically you could make a UWP app run "out of sandbox" by adding that capability and just never doing anything with the logged failures?

@WildByDesign
Copy link

Would this mean that theorically you could make a UWP app run "out of sandbox" by adding that capability and just never doing anything with the logged failures?

Yes, that is correct as long as you are on Windows 11. It still runs as Low IL AppContainer, or Full Trust as you may have it, but the app has full access to the file system, network, registry, etc. Zero restrictions in my testing so far.

Sorry for the off-topic.

forderud added a commit to forderud/ToastNotifier that referenced this issue May 16, 2022
Based on suggestion on microsoft/WindowsAppSDK#219

Leads to the following error:
1>MakeAppx : error : Error info: error 80080204: App manifest validation error: Line 31, Column 24, Reason: The "windows.aboveLockScreen" Extension can't be declared with Partial Trust EntryPoint.
1>MakeAppx : error : Package creation failed.
1>MakeAppx : error : 0x80080204 - The specified package format is not valid: The package manifest is not valid.
forderud added a commit to forderud/ToastNotifier that referenced this issue May 29, 2022
Based on suggestion on microsoft/WindowsAppSDK#219

Leads to the following error:
1>MakeAppx : error : Error info: error 80080204: App manifest validation error: Line 31, Column 24, Reason: The "windows.aboveLockScreen" Extension can't be declared with Partial Trust EntryPoint.
1>MakeAppx : error : Package creation failed.
1>MakeAppx : error : 0x80080204 - The specified package format is not valid: The package manifest is not valid.
forderud added a commit to forderud/ToastNotifier that referenced this issue May 30, 2022
Based on suggestion on microsoft/WindowsAppSDK#219

Leads to the following error:
1>MakeAppx : error : Error info: error 80080204: App manifest validation error: Line 31, Column 24, Reason: The "windows.aboveLockScreen" Extension can't be declared with Partial Trust EntryPoint.
1>MakeAppx : error : Package creation failed.
1>MakeAppx : error : 0x80080204 - The specified package format is not valid: The package manifest is not valid.
forderud added a commit to forderud/ToastNotifier that referenced this issue May 30, 2022
Based on suggestion on microsoft/WindowsAppSDK#219

Leads to the following error:
1>MakeAppx : error : Error info: error 80080204: App manifest validation error: Line 31, Column 24, Reason: The "windows.aboveLockScreen" Extension can't be declared with Partial Trust EntryPoint.
1>MakeAppx : error : Package creation failed.
1>MakeAppx : error : 0x80080204 - The specified package format is not valid: The package manifest is not valid.
forderud added a commit to forderud/ToastNotifier that referenced this issue May 30, 2022
Based on suggestion on microsoft/WindowsAppSDK#219

Leads to the following error:
1>MakeAppx : error : Error info: error 80080204: App manifest validation error: Line 31, Column 24, Reason: The "windows.aboveLockScreen" Extension can't be declared with Partial Trust EntryPoint.
1>MakeAppx : error : Package creation failed.
1>MakeAppx : error : 0x80080204 - The specified package format is not valid: The package manifest is not valid.
@torarnv
Copy link

torarnv commented Oct 14, 2022

@ptorr-msft @nickrandolph I'm struggling to change the packaging project to partial trust, is this still working? I've removed the runFullTrust capability, but do not see any new property for the linked application:

image

And trying to set the entrypoint manually in the manifest seems to be ignored and overridden each time:

image

And results in a validation error when building:

image

Any ideas?

(I'm trying to make my app partial trust, so that I can test AppCapabilities checks and requests for webcam, microphone, etc. When fullTrust is in effect all these capabilities are granted by default, without any way to request them)

@DrusTheAxe
Copy link
Member

What is line 25, column 6 in your appxmanifest.xml?

Offhand it sounds like your Application definition should get you what you want. This could be something else. There can be things in appxmanifest.xml that require runFullTrustCapability beyond the Application declaration itself e.g. `<Extension Category="windows.firewallRules"...> requires the package declares the runFullTrustCapability even though the firewall rules are just definitions to the firewall (that extension's not an activatable extension point).

@torarnv
Copy link

torarnv commented Oct 14, 2022

@DrusTheAxe The line 25 column 6 refers to the generated AppManifest.xml, containing:

<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" IgnorableNamespaces="uap rescap build" xmlns:build="http://schemas.microsoft.com/developer/appx/2015/build">
  <!--
    THIS PACKAGE MANIFEST FILE IS GENERATED BY THE BUILD PROCESS.

    Changes to this file will be lost when it is regenerated. To correct errors in this file, edit the source .appxmanifest file.

    For more information on package manifest files, see http://go.microsoft.com/fwlink/?LinkID=241727
  -->
  <Identity Name="7827e4e6-37f5-413d-86dd-1b409ad905fd" Publisher="CN=Tor Arne Vestbø" Version="1.0.1.0" ProcessorArchitecture="x64" />
  <Properties>
    <DisplayName>PermissionsPackagingProject</DisplayName>
    <PublisherDisplayName>Tor Arne Vestbø</PublisherDisplayName>
    <Logo>Images\StoreLogo.png</Logo>
  </Properties>
  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.14393.0" MaxVersionTested="10.0.22000.0" />
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14393.0" MaxVersionTested="10.0.22000.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.30704.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>
  <Resources>
    <Resource Language="EN-US" />
  </Resources>
  <Applications>
    <Application Id="App" Executable="permissions\permissions.exe" EntryPoint="Windows.FullTrustApplication">
      <uap:VisualElements DisplayName="PermissionsPackagingProject" Description="PermissionsPackagingProject" BackgroundColor="transparent" Square150x150Logo="Images\Square150x150Logo.png" Square44x44Logo="Images\Square44x44Logo.png">
        <uap:DefaultTile Wide310x150Logo="Images\Wide310x150Logo.png" />
        <uap:SplashScreen Image="Images\SplashScreen.png" />
      </uap:VisualElements>
    </Application>
  </Applications>
  <Capabilities>
    <Capability Name="internetClient" />
  </Capabilities>
  <build:Metadata>
    <build:Item Name="Microsoft.Build.DesktopBridge.Tasks.dll" Version="17.3.32727.363" />
    <build:Item Name="TargetFrameworkMoniker" Value=".NETFramework,Version=v4.5.1" />
    <build:Item Name="VisualStudio" Version="17.0" />
    <build:Item Name="VisualStudioEdition" Value="Microsoft Visual Studio Professional 2022" />
    <build:Item Name="OperatingSystem" Version="10.0.22000.1 (WinBuild.160101.0800)" />
    <build:Item Name="Microsoft.Build.AppxPackage.dll" Version="17.3.32728.75" />
    <build:Item Name="ProjectGUID" Value="39ea0d78-5270-49c4-b6d6-5759506d77ee" />
    <build:Item Name="makepri.exe" Version="10.0.22621.1 (WinBuild.160101.0800)" />
  </build:Metadata>
</Package>

Line 25 is the one with <Application ..., so I assume it's the EntryPoint="Windows.FullTrustApplication" part that's causing it.

Yet the Package.appxmanifest that's part of the packaging project contains:

<?xml version="1.0" encoding="utf-8"?>

<Package
  xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
  xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
  xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
  IgnorableNamespaces="uap rescap">

  <Identity
    Name="7827e4e6-37f5-413d-86dd-1b409ad905fd"
    Publisher="CN=Tor Arne Vestbø"
    Version="1.0.1.0" />

  <Properties>
    <DisplayName>PermissionsPackagingProject</DisplayName>
    <PublisherDisplayName>Tor Arne Vestbø</PublisherDisplayName>
    <Logo>Images\StoreLogo.png</Logo>
  </Properties>

  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.0.0" MaxVersionTested="10.0.0.0" />
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14393.0" MaxVersionTested="10.0.14393.0" />
  </Dependencies>

  <Resources>
    <Resource Language="x-generate"/>
  </Resources>

  <Applications>
    <Application Id="App"
      Executable="$targetnametoken$.exe"
      EntryPoint="Windows.PartialTrustApplication">
      <uap:VisualElements
        DisplayName="PermissionsPackagingProject"
        Description="PermissionsPackagingProject"
        BackgroundColor="transparent"
        Square150x150Logo="Images\Square150x150Logo.png"
        Square44x44Logo="Images\Square44x44Logo.png">
        <uap:DefaultTile Wide310x150Logo="Images\Wide310x150Logo.png" />
        <uap:SplashScreen Image="Images\SplashScreen.png" />
      </uap:VisualElements>
    </Application>
  </Applications>

  <Capabilities>
    <Capability Name="internetClient" />
  </Capabilities>
</Package>

Where I've explicitly tried to override the entrypoint to Windows.PartialTrustApplication

@DrusTheAxe
Copy link
Member

My guess is the VS task transforming package.appxmanifest to appxmanifest.xml is rewriting EntryPoint based on its logic and project properties, regardless what's in the package.appxmanifest.

@Scottj1s @MikeHillberg @evelynwu-msft is there a way to do this with the current templates? Perhaps explicitly adding some property?

This screen shot
differs from the 2nd image here. Notice the properties page there has Trust Level in the latter and not the former. Is something missing in the template to get that to appear?

@evelynwu-msft
Copy link
Contributor

"packaging project" means .wapproj is being utilized? @sbanni is it possible to configure a .wapproj to produce a partial trust application?

@torarnv
Copy link

torarnv commented Oct 17, 2022

"packaging project" means .wapproj is being utilized?

Correct. Generated by the Visual Studio "Windows Application Packaging Project" wizard, following this guide https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-packaging-dot-net

@sbanni
Copy link

sbanni commented Oct 17, 2022

"packaging project" means .wapproj is being utilized? @sbanni is it possible to configure a .wapproj to produce a partial trust application?

@evelynwu-msft Yes, select the project reference node in the packaging project and it is available as a property:
image

@torarnv
Copy link

torarnv commented Oct 17, 2022

@sbanni That's not the case for me:

image

I notice your project is a .csproj, while mine is a .vcxproj. Does that matter?

@torarnv
Copy link

torarnv commented Oct 17, 2022

This is after creating a new C++ Desktop Application, and then adding the packaging project:

image

@sbanni
Copy link

sbanni commented Oct 17, 2022

I notice your project is a .csproj, while mine is a .vcxproj. Does that matter?

@torarnv Interesting, looks like vcxproj doesn't expose it, you should be able to achieve the same outcome by setting this property in the packaging project file:

<ProjectReference Include="..\WpfApp12\WpfApp12.csproj">
  <TrustLevel>Partial</TrustLevel>
</ProjectReference>

@torarnv
Copy link

torarnv commented Oct 17, 2022

Thanks for the hint @sbanni! I tried this, but doesn't look like it's accepted?

image

@sbanni
Copy link

sbanni commented Oct 17, 2022

Thanks for the hint @sbanni! I tried this, but doesn't look like it's accepted?

@torarnv You should be able to ignore the green squiggles, it should build fine with it, I just tested it locally and and it generated the appxmanifest with the partialtrust entry.

@torarnv
Copy link

torarnv commented Oct 17, 2022

You're right! It actually seems to work. At first I got this when building:

image

But after bumping that, the resulting XML now has:

image

Hurray! 🥳

@torarnv
Copy link

torarnv commented Oct 17, 2022

Thanks a bunch @sbanni 🙌🏻👏🏻❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-AppContainer area-Win32 Support for Win32 packaged and non-packaged apps feature
Projects
None yet
Development

No branches or pull requests