What is IL (Integrity level) of WindowsAppSDK apps?

[rajendrasp]

I see there are different types of apps can use WindowsAppSDK. In samples folder, I see following:

What is the IL (integrity level) for these different types of apps?

I am specifically interested in

1. cpp-win32-packaged
2. cpp-win32-unpackaged
3. cpp-winui-packaged

Is cpp-winui-packaged app any different from UWP apps (which were using Windows.UI.XAML) other than new XAML controls?

[castorix]

You can do a test for each app by calling OpenProcessToken/GetTokenInformation with TokenIntegrityLevel
(you can check the result by calling IsWellKnownSid with WinLowLabelSid, WinMediumLabelSid, etc...)

[DarranRowe]

To start off, any unpackaged application, including unpackaged WinUI 3, is always going to run outside of an app container. Of course, the mandatory integrity level can always be set, but any unpackaged application will have the default of medium.
For packaged applications, whether the application runs in an app container depends completely on the package settings. If you look at the AppX manifest documentation entry for Application. It states the following under uap10:TrustLevel:
""appContainer" - the app runs in a lightweight app container; its process runs with an integrity level of low."
So, you can tell the package to run in an app container, the integrity also depends on this setting. But even if you set the package to run in an app container, it will different to a UWP application.
A packaged application will run in the context of a desktop application. This means that CoreApplication and CoreWindow are unavailable and anything that relies on these are unavailable. While you can use other things in the UWP namespaces, some of these WinRT components are just completely unavailable while others require the use of an interop interface to create instances. So yes, a packaged WinUI 3 application has differences to a Xaml UWP application.

[DarranRowe]

@DrusTheAxe
I was messing around with things and I saw how things work, so getting an application in an app container is interesting. This did pique my curiosity a little. Do you know if there is more in depth documentation for this? Or is this another case of things being woefully under/undocumented?
I know that it would probably be easier to set things up as a package with external location, setting the runtime behaviour to packageClassicApp and the trust level to appContainer, but curiosity is one of those things.

[DrusTheAxe]

AppContainer for unpackaged apps is documented e.g.

• AppContainer for Legacy Applications

• AppContainer Isolation

• Implementing an AppContainer

• GetTokenInformation() called with TokenIsAppContainer (boolean is/not), TokenAppContainerSid, TokenAppContainerNumber and TokenIsLessPrivilegedAppContainer

• NtCreateLowBoxToken function (AppContainer was originally called 'LowBox' and renamed sometime during Win8 before release)

• WIL's token_helpers.h has some appcontainer aids e.g. get_token_is_app_container_nothrow()

and more hits e.g. https://learn.microsoft.com/en-us/search/?scope=Desktop&terms=appcontainer

Packaged apps have an easier time of it as registering a package for a user creates a an AppContainer profile (i.e. AC definition, needed to create a process in an AC), and deregistering the package for the user removes the AC profile. There's Win32 APIs to do this (e.g. the Deployment stack uses them when (de)registering a package) but it can get complicated. MSIX for the win :-)

Packaged apps declare an or in their appxmanifest.xml with uap10:TrustLevel="appContainer" or the older EntryPoint="windows.partialTrustApplication" syntax (or omit and define a UWP app) and Windows spins up the process in an AppContainer when activated. See Combinations of activation info attributes for more info.

Unpackaged processes can be created in an AppContainer but you need to do more legwork when you create the process. See the links above.

The one commonality across packaged and unpackaged apps is when you code needs to ask, "Am I running in an AppContainer?" Then GetTokenInformation(...TokenIsAppContainer...) (or WIL equivalents) is your friend.

TokenIsLessPrivilegedAppContainer refers to a Least Privileged AppContainer (LPAC). Many resources across Windows are ACL'd with ALL_APPLICATION_PACKAGES¹ to grant access to any processes in an AppContainer. Many Windows APIs need access to resources that would normally be inaccessible to AppContainers unless you changed their ACL (and some of these are system resources only Windows can do so). To solve this ALL_APPLICATION_PACKAGES was applied to various files, regkeys, etc to ensure apps running in an AppContainer run correctly. However, there are times you really do want a process running with no rights to any resources except what you explicitly grant them (e.g. a web browser sandboxing a child worker process). In these cases an AC has too much access to the system. An LPAC is effectively an AppContainer that doesn't meet the ALL_APPLICATION_PACKAGES criteria. You can't create an LPAC declaratively via appxmanifest.xml, only via APIs. You can find more info around the web if you're interested.

¹ ALL_APPLICATION_PACKAGES is a misnomer. In hindsight, ALL_APPCONTAINERS would be the more accurate name but the term was defined early in Win8 and renaming it (and the zillions of references, in Windows and across the ecosystem) would be rather painful for little gain.

[DrusTheAxe]

P.S. If you find Microsoft's documentation in need of improving please share your feedback.

Packaged apps have supported AppContainer from day 1 and it's gotten a bit more expansive over the years. But it's never been as interesting to as broad an audience as other topics so it wouldn't surprise me if you find the documentation isn't as extensive as other topics (or as needed / desired).

[DarranRowe]

@DrusTheAxe
Thank you for spending the time gathering this information. After spending time looking through the information I didn't find, I can see how complete things are.
From everything I have read, the biggest thing the documentation is missing is an article just grouping things together. Something like a "Using AppContainer for Legacy Applications" article. It would be useful if this made you aware of the profile functions to set up the app container profile. It would also be nice if this would also show you how to start the process using CreateProcess with the extended startup info.
Otherwise, I would say the remaining issues are pretty small. Clearing up the App/AppContainer issue would be nice. For example, the CreateAppContainerProfile description starts with:
"Creates a per-user, per-app profile for Windows Store apps."
It is not immediately obvious how you need to handle capabilities. For both CreateAppContainerProfile and STARTUPINFOEX, the capabilities are represented as PSID_AND_ATTRIBUTES. The DeriveCapabilitySidsFromName function hints at this a little with one of the results being "GroupSids with NTAuthority". But the only documentation I found explicitly stating they are groups is GetTokenInformation where the type returned for TokenCapabilities is the TOKEN_GROUPS structure.
There is nothing stating the relationship between the capabilities specified when creating the profile using CreateAppContainerProfile and the capabilities provided in the SECURITY_CAPABILITIES structure.
The documentation for UpdateProcThreadAttribute doesn't even list PROC_THREAD_ATTRIBUTE_ALL_APPLICATION_PACKAGES_POLICY. This is what the Privexec repository uses to enable the LPAC.
Finally, I think making it clear that the capabilities are the UWP capabilities.

I do understand that this is pretty low priority since packaging the application is definitely an easier solution. But I also know that I have run into a situation where I had to deal with untrusted things where packaging wasn't possible and knowing that an app container was available and how to use it would have really helped. Currently, there is the problem of having to know what functionality you have to use to find the documentation for it.

[DrusTheAxe]

We're always interested to hear where docs could be improved. Sometimes we can be too close to notice things, so community input is highly valued to help us see what we may be missing.

We'd love to see more folks - packaged and unpackaged - embrace AppContainer, for all the usual Good Engineering Practices reasons. Docs certainly play a role in helping head in that direction. I've passed along word for follow up. I have no idea about priorities or timelines, but it's on the radar.

Thanks for the feedback.