sylveon commented 4 years ago

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:

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: https://github.com/microsoft/WinDev/issues/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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ptorr-msft commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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.

sylveon commented 3 years ago

A fairly high visibility TikTok post has now managed to slander my app and my overall credibility specifically because of the way the Store words out the runFullTrust capability. I am furious.

The capability's description should be at least changed as long as AppContainer for Win32 is not a viable solution for app developers.

ptorr-msft commented 3 years ago

First, I am sorry to hear that someone is (incorrectly) asserting that a full-trust app is a scam. It's a trivially-provable false statement but unfortunately I don't think there's anything we can do about it. Are you able to reach out to the TikTok author directly to educate them about your app (and permissions in general)?

Secondly, to the question of changing the wording, unfortunately we are unlikely to do that either. The text was crafted to be as technically-correct as possible whilst still being understandable by a non-technical user. Even though your app only uses FT to add a tray icon, we can't add specific permissions text for every possible use-case. Also, while any given FT app might not cause any harm by itself, it could theoretically be an attack vector for some malware that leverages privileges to do harm. I realize this might be unlikely in your case, but again we can't have special-cased wording for different apps. Nevertheless, if you have a suggestion for how the wording can be improved, you are welcome to provide it although I'm 99.9% certain it won't be changed.

One thing you could do on your Store app page is mention why your app has FT (to use Shell features) and proactively point to your privacy policy and the GitHub source for people to check themselves (I know they're linked at the bottom of the page, but they're kind of hidden amongst all the copyright info and other minutiae)

hummeleBop commented 3 years ago

I'm also searching a way to use limited capabilities in my win32 app on the store. Electron seems able to do that, is it really available right now ?

JaiganeshKumaran commented 3 years ago

This should be done. MSIX desktop apps running with partial trust will be more secure. Unless full system access is needed, better run all apps in an AppContainer even if they are not UWP apps.

JaiganeshKumaran commented 3 years ago

One problem with the packaging project requires the runFullTrust restricted capability even if you set EntryPoint="Windows.PartialTrustApplication" in the Application node

ptorr-msft commented 3 years ago

First you need to manually delete the runFullTrust entry from the Package.appxmanifest file, then there should be a property on the target project inside the Applications node to say you want partial trust:

Does that work?

nickrandolph commented 3 years ago

What @ptorr-msft said should work. I've covered it a bit more here: https://nicksnettravels.builttoroam.com/trust-appcontainers/

lukeblevins commented 3 years ago

Back in December, there was some slight commotion about the Store giving users signals that FullTrust-capable apps had essentially unfettered access to critical functionality like their filesystem and registry. One concerned user brought these allegations onto social media and the rest (as we all know) happened very quickly resulting in what I'm sure was damage to the crucial developer-user trust contract.

With this scenario in mind, I believe the Windows team should leverage learnings from it to improve the user experience with both registered and unregistered (and potentially unpackaged) applications:

Windows users DO take security seriously, especially when it means data loss or altered device performance
Generally, users of curated app distribution mechanisms like the Microsoft Store, Apple App Store, or Google Play Store place trust in them to correctly present both the risks and benefits of a potential application's requested capabilities.
Developer context around requested capabilities is important at install-time
The all-or-nothing approach to application trust models is not ideal in 2021

Since this last observation is worth expanding on, I'll go into more detail

Building an application trust model for the new Windows

The incentives which arise from the present choice for developers between FullTrust and a crippled PartialTrust almost always results in a lacking user experience. This is because developers correctly observe they must forfeit the PartialTrust, capability declaration system traditionally found in packaged WinRT apps just to use/continue using the more robust Win32 APIs.

Notably, one important consideration is how often developers will, without proper guidance, default to giving their applications access to the full breadth of Windows capabilities. It's similarly important to acknowledge that many apps require this level of access, but the capability request system starts to become undermined when developers do this unecessarily. For instance, modern versions of Ubuntu have a different kind of app packaging system called Snap. Because developers would need to rewrite or repackage their apps to work within a "confined" setting, many just opt for minimal or no confinement.

What Windows needs is some kind of ExtendedPartialTrust security model (by default) where the system actively intercepts API calls of unregistered, unpackaged apps at the process level and grants access to resources (webcam, filesystem, location) based on user preferences.

Apps that opt out of this new security model should still be treated like first class citizens in the Store, but both the developers and Microsoft (through warnings to scare Grandma) should present their case at install time.

I know things are busy with the WindowsAppSDK at the moment, so I'm especially excited for future announcements on this front. I'm optimistic that Microsoft will take a responsible approach to this since they're allowing unpackaged apps into the Store now.

riverar commented 3 years ago

I know things are busy with the WindowsAppSDK at the moment, so I'm especially excited for future announcements on this front. I'm optimistic that Microsoft will take a responsible approach to this since they're allowing unpackaged apps into the Store now.

Nit: runFullTrust apps and unpackaged apps are generally the same from a security boundary perspective (i.e. there is none), so there is no change in Store behavior here. That is, the Store continues to distribute both potentially unsafe and safe sandboxed apps.

ghost commented 3 years ago

This should be Windows App SDK's next concern/ area for innovation.
AppContainer/partial trust /crippled trust / extented partial trust /no trust whatever the name is win32 apps asking for users permission is a must. previously we were told appcontainer were needed for permissions model to be enforced.
make sure you fix the storage broker too , it's single threaded and super slow. we don't want our win32 apps to be as slow as the likes of UWP ones. Appcontainer's point should be only around security not making native apps slow.
when WinRT apis are used, remove your useless storage broker gatekeeper (RuntimeBroker.exe) for medium IL/high IL process even if the app is packaged.

ptorr-msft commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

torarnv commented 2 years ago

@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:

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

And results in a validation error when building:

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

torarnv commented 2 years ago

"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 commented 2 years ago

"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:

torarnv commented 2 years ago

@sbanni That's not the case for me:

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

torarnv commented 2 years ago

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

sbanni commented 2 years ago

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 commented 2 years ago

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

sbanni commented 2 years ago

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.

microsoft / WindowsAppSDK

AppContainer for Win32 apps #219

Proposal: AppContainer for Win32 apps

Summary

Rationale

Scope

Important Notes

Open Questions

Scope

Open Questions/Rationale:

Building an application trust model for the new Windows