[Inquiry]: Are MSIX packaged Win32 apps already being sandboxed from hardware?

[mikehearn]

Description

I note the following comment in the docs:

https://learn.microsoft.com/en-us/windows/win32/secauthz/app-isolation-supported-capabilities

Win32 app isolation supports most of the UWP capabilities. These capabilities might be necessary for a fully operational isolated app's manifest.

I got a report today that one of my user's Flutter apps (packaged with MSIX) couldn't access the webcam or microphone until the uap:voipCall capability was added. This is strange, because the app doesn't opt-in to any form of sandboxing in any way. However, it also doesn't specify the uap10:TrustLevel=mediumIL attribute on the Application tag. It's not required, but the docs don't say what happens if you don't specify this.

I'm hoping you sandboxing experts can help clear this up - if you specify EntryPoint="Windows.FullTrustApplication" but nothing else on an Application tag, and specify rescap:runFullTrust as the capability, and then install via MSIX, what level of sandboxing is applied?

[mominshaikhdevs]

this sounds like an area of expertise of @DrusTheAxe.

[DrusTheAxe]

https://learn.microsoft.com/en-us/windows/win32/secauthz/app-isolation-supported-capabilities

Well that's terribly confusing. The phrase "app isolation" is a new one by me. The page also says 'app isolation' is in preview. I'm not sure if that's current. I've poked some folks.

But the sub page https://learn.microsoft.com/en-us/windows/win32/secauthz/app-isolation-packaging-with-vs is much clearer (to me) -- uap18:RuntimeBehavior="appSilo".

App silo is another option for RuntimeBehavior. Mechanically, to use it for an activatable extension point you need

uap18:RuntimeBehavior="appSilo"
uap18:TrustLevel="appContainer"

(NOTE: RB=appSilo requires TL=appContainer. AppSilo doesn't support TL=mediumIL)

Conceptually, think of TL=appContainer as a sandbox where if you touch resources you don't have rights to touch you get E_ACCESSDENIED. AppSilo is similar, but instead of access denied you get a brokered experience -- "Hey user, is it cool for this app to use that resource?" and if yes, Windows remembers their answer and grants you access to the resource (success, not fail/accessdenied). This sandboxed/brokered experience requires the AppContainer box to do its thing, hence the reason RB=appSilo requires TL=appContainer

To use AppSilo specify RB+TL and don't specify EntryPoint. Technically you need RB+TL or EP; you can specify EP + RB and/or TL, but if you do they need to be consistent. As the only way to specify appsilo is RB=appSilo and there's no EP value to match, they'd be inconsistent and manifest validation will fail.

And since RB=appSilo requires Tl=appContainer and you are running in an AppContainer, you can specify capabilities to request access to resources. This is same how UWP apps use capabilities because they run in an AppContainer. Capabilities relate to AppContainer (the 'UWP app-ness' doesn't really factor in to the capability story. It's the fact UWP apps run in an AppContainer why capabilities come into play).

Does that help?

Those docs are definitely bugged (due to preview-ness?). I'll poke the right folks to take care of it. Thanks for bringing it to our attention.

[DrusTheAxe]

P.S. There's a nifty trick feature :-) here. AppSilo requires Windows 24H2 but the uap18:RB+TL attributes act as overrides if present, so you can make 1 package that runs uplevel in AppSilo and runs downlevel without it

For example, to run in AppSilo on supported platforms and degrade gracefully downlevel to 20H1 running as DesktopBridge/MediumIL do this

<Application ...
    uap10:RuntimeBehavior="packagedClassicApp" uap10:TrustLevel="mediumIL"
    uap18:RuntimeBehavior="appSilo" uap18:TrustLevel="appContainer">

And if you want same but downlevel to RS1 do this

<Application ...
    EntryPoint="windows.fullTrustApplication"
    uap18:RuntimeBehavior="appSilo" uap18:TrustLevel="appContainer">

(uap10:RB+TL first appeared in 20H1)

In theory you could also run downlevel in AppContainer, but if you do I don't see why you'd need AppSilo. If you're good in an AppContainer why run less securely on more recent systems via AppSilo? If you have no problem with AppContainer downlevel why would you need AppSilo's brokering aids on newer systems?

[DrusTheAxe]

if you specify EntryPoint="Windows.FullTrustApplication" but nothing else on an Application tag, and specify rescap:runFullTrust as the capability, and then install via MSIX, what level of sandboxing is applied?

EntryPoint="Windows.FullTrustApplication"

is synonymous with

uap10:RuntimeBehavior="packagedClassicApp" uap10:TrustLevel="mediumIL"

Only difference is uap10:RB+TL are supported down to 20H1 whereas EP=windows.fullTrustApplication is supported down to RS1.

Most folks would call mediumIL a "security context" rather than a "sandbox" but I get your question. Hopefully this provides the answers you seek.

P.S. Sorry, I don't recall the various 10.0.x.0 build numbers for 20H1/RS5/etc. I find Wikipedia's Win10 version history page handy to jog my memory when I need to know such fine print.

[mikehearn]

Thanks for the info! My question was whether Windows does any sandboxing at all when EntryPoint="Windows.FullTrustApplication". My understanding was no, and that understanding is re-inforced by what you just said: mediumIL is basically a package-labelled app context with a bit of VFS redirection and not a sandbox as such.

However, that seems to be contradicted by real world bug reports in which some VOIP library didn't work until a permission was added to the MSIX manifest. Hence my question to Windows sandboxing experts: why do permissions make a difference if running at medium IL? That's wrong, isn't it? Maybe there's a bug here? Unfortunately this bug report came from a user (my "users" are developers shipping apps with my deployment tool, which uses MSIX).