Closed riverar closed 10 months ago
tiangao-ms
commented
1 year ago Sorry could you explain why you think the capability is not working? This is a feature that allows access to a very specific (and manually created) directory. Did you test it?
riverar
commented
1 year ago I expected the capability named "access to publisher directory" to control, well, access to the directory in which the app is published to. I recognize now, after finding the separate docs, this is not supported. (https://github.com/microsoft/win32-app-isolation/blob/main/docs/fundamentals/consent.md)
Perhaps it should? The files in the summary.txt above are pretty critical.
tiangao-ms
commented
1 year ago This is @macruzco 's expertise area. I do believe that the app has access to the directory it's installed in (so all the installed files). Are you able to bring up your app without the profiler?
macruzco
commented
1 year ago Hi @riverar,
Please find a few questions for troubleshooting below:
1) summary.txt is appended to by every new run, not overwritten. Are you looking into the summary.txt contents for the run of the package you registered in place? 2) Was the AppXManifest located in the installation directory of the application? If not, what happens when you try that? 3) Did you Start-Profiling again for the new package manifest? Did it complain about the package not being installed? 4) Do you run into the same issue if you create an MSIX package via MPT using the new AppXManifest with the isolatedWin32-accessToPublisherDirectory capability? 5) Do you see lines for the \??\C:\Sources\EarTrumpet\EarTrumpet.Package\AppPackages\40459File-New-Project.EarTrumpet\EarTrumpet* files in the AccessAttemptRecords.csv generated by Get-ProfilingResults run for the package registered in place? If so, could you please send me one or two of those lines?
Good catch nonetheless! Generally speaking, I know the isolated app would have access to install directories under ProgramFiles, but I'm not sure if default access would be supported for other installation paths.
Thank you!
DrusTheAxe
commented
1 year ago Add-AppxPackage -Register path is equivalent to PackageManager.RegisterPackageAsync(file://path, DeploymentOptions_DevelopmentMode). That has differences if you register the package w/o DevelopmentMode. The cmdlet sets that option by default; you need to add -DisableDevelopmentMode for the cmdlet to NOT pass that option to PackageManager when registering the package.
the app has access to the directory it's installed in (so all the installed files)
Please define "access".
In general, yes - Windows.ApplicationModel.Package.Current.InstalledPath (or GetCurrentPackagePath(), etc) gets an app the location its installed in (aka its packagedirectory aka pkgdir), but the directory may be ACL'd in ways that don't work for certain types of access e.g. no write access to a pkgdir when under C:\Program Files\WindowsApps, not all ACEs are added when the pkg is registered.
I'm not familiar with isolatedWin32-accessToPublisherDirectory, so I can't say if/how that alters behavior.
macruzco
commented
1 year ago It seems like the problem may be that the directory impacted is not ACL'ed to allow the necessary access by the package, which wouldn't be changed by registration.
@riverar could you please send us the Security Descriptor on the impacted package directory in the following three instances: 1) Before Add-AppxPackage -Register. 2) After Add-AppxPackage -Register in the broken scenario. 3) After Add-AppxPackage -Register in the working scenario.
Thank you!
riverar
commented
1 year ago Hi @macruzco, here's my results.
App
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
DESKTOP-4P4GJJ1\Rafael:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)App
+ S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(RX)
+ S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(OI)(CI)(IO)(GR,GE)
+ NT AUTHORITY\SYSTEM:(F)
+ NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
+ NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(RX)
+ NT AUTHORITY\NETWORK SERVICE:(OI)(CI)(RX)
+ NT AUTHORITY\RESTRICTED:(OI)(CI)(RX)
+ BUILTIN\Users:(OI)(CI)(Rc,S,RD,REA,X,RA)
+ S-1-15-3-2386727626-4250381418-2784579416-2751325192-2387952516-4069137933-1462935302:(OI)(CI)(RX)
+ BUILTIN\Users:(OI)(CI)(R)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
DESKTOP-4P4GJJ1\Rafael:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)And here's a fresh set of files after adding isolatedWin32-accessToPublisherDirectory.
When I originally created this issue, I thought isolatedWin32-accessToPublisherDirectory would address the file-based hits, such as:
\??\C:\Sources\IsolationRepros\register-in-place\App\EarTrumpet\EarTrumpet.exe.config
\??\C:\Sources\IsolationRepros\register-in-place\App\EarTrumpet\EarTrumpet.exe
\??\C:\Sources\IsolationRepros\register-in-place\App\EarTrumpet\EarTrumpet.PDB
...Thank you, @riverar ! This is helpful and opens up avenues for investigation on my end. I'll keep you posted.
macruzco
commented
1 year ago @riverar , at your convenience, could you please send me step-by-step instructions on how you hit this problem?
The S-1-15-3-2386727626-4250381418-2784579416-2751325192-2387952516-4069137933-1462935302:(OI)(CI)(RX) ACE added by Add-AppxPackage -Register to the package directory should be enough to confer the access your package needs. However, observing the trace you sent us, it looks like your package activation did not work as expected.
I tried reproing this using my fork of EarTrumpet and your AppSilo AppXManifest, but things worked as expected for me.
riverar
commented
1 year ago Video: https://www.youtube.com/watch?v=N1waBtr3NA4 (quickly put together)
Files on desktop from video: Video_Assets.zip
Missing from the video is a third attempt that adds the remaining capabilities the tool found:
<rescap:Capability Name="inputInjection"/>
<rescap:Capability Name="isolatedWin32-profilesRootMinimal"/>Running the app resulted in the same app behavior as seen in the video--can't click toggle switches, etc.
macruzco
commented
1 year ago Hi @riverar , thank you for this!
The traces you sent me point to the culprit being activation issues for the package, where access primitives set by register in-place are not translated as expected to the package token upon activation. Although that's clear from the traces, I wasn't able to repro it to understand why that's happening. See below for details. I'll pursue other avenues of investigation and keep you posted. Activation might have some trace logs we can collect from your machine to help understand what's happening.
I tried reproing this using my fork of EarTrumpet and your AppSilo AppXManifest, but things worked as expected for me.
By the above I don't mean EarTrumpet worked as expected, with toggles and functionality operating smoothly, etc. These are separate issues/investigations. What I mean is that the issue at hand of denied access to the package directory registered in place did not repro. The package was able to access those resources after being registered in place.
I ran your scenario according to the video on a clean 25393.1.amd64fre.zn_release.230608-1158 client Enterprise VM (matching the build on your video) with developer mode enabled from an Administrator PowerShell 7 terminal.
I was not able to repro the denied access. After register in place, both with and without capabilities declared, the package was granted Read and Execute access to the target package directory. You can find the results of my repro attempt below. If you can think of anything that may help me repro this that is not in the video, a machine setting or a particular step in the video I should be paying special attention to, please let me know.
At this point, the best bet to resolve the issue at hand would probably be to try a clean machine. Although if you decide to do this, please keep the machine that repros the issue live if you can, in case we need to get back to it for more diagnostics.
Just to clarify, the isolatedWin32-accessToPublisherDirectory capability has a misleading name. It's not intended to grant access to the package directory in the register in place scenario. It's intended for publishers of packages to allow for multiple such packages to access a common publisher path as long as that path includes the publisher ID. We are working on clarifying the intent and perhaps the name of the capability.
Thank you, Matheus
riverar
commented
1 year ago The trace/logs I provided were from a clean virtual machine; I can give you full RDP access to the box if needed.
But I think I lost track of what the goal of all this troubleshooting was. It sounds like you already confirmed isolatedWin32-accessToPublisherDirectory is not designed to grant access in the register-in-place scenario so the following entries in the README.txt are expected behavior with no current workaround, right? (If so, that loops us back to my original feature request.)
Type: File
\??\C:\Sources\IsolationRepros\register-in-place\App\EarTrumpet\EarTrumpet.exe.config
\??\C:\Sources\IsolationRepros\register-in-place\App\EarTrumpet\EarTrumpet.exe
\??\C:\Sources\IsolationRepros\register-in-place\
\??\C:\Sources\
\??\C:\Sources\IsolationRepros\
\??\C:\Sources\IsolationRepros\register-in-place\App\
\??\C:\Sources\IsolationRepros\register-in-place\App\EarTrumpet\
...Right, the issues are conflated here. Thanks for bearing with this, please let me know if the below makes things clearer.
isolatedWin32-accessToPublisherDirectory does not apply to register in place, so we don't need to think of the issue in terms of this capability at all.
If so, that loops us back to my original feature request
As far as adding support for packages registered in place, the icacls output you sent us and my repro attempts tell us that packages registered in place are already supported.
As per icacls, Add-AppxPackage -Register adds the appropriate ACE to the registered package directory to make sure the package can read and execute its contents, namely:
S-1-15-3-2386727626-4250381418-2784579416-2751325192-2387952516-4069137933-1462935302:(OI)(CI)(RX)
The SID above is a capability specific to your package, where the RIDs in bold are derived from your package name. The package token should have this capability "by default". It's not something declared in the manifest.
In my repro attempt, the package token correctly carries the S-1-15-3-2386727626-4250381418-2784579416-2751325192-2387952516-4069137933-1462935302 capability as expected. Thus, you'll see in my repro files that nothing under \??\C:\Sources\IsolationRepros\register-in-place\App (i.e., the registered directory) was flagged for denied access.
so the following entries in the README.txt are expected behavior with no current workaround, right?
No. Some of the entries, namely anything under \??\C:\Sources\IsolationRepros\register-in-place\App, are not expected and should not have appeared in summary/readme even in the case where you had no capabilities declared in the manifest. As it stands today, your package should have been able access to anything under \??\C:\Sources\IsolationRepros\register-in-place\App after being registered in place.
The traces you sent me show that, specifically in the scenario you ran on your VM, the package's token was not created with the "default" package capability (S-1-15-3-2386727626-4250381418-2784579416-2751325192-2387952516-4069137933-1462935302) like it should have been. This leads to your package not being able to access anything under \??\C:\Sources\IsolationRepros\register-in-place\App and to entries for this directory showing up in the summary/readme files. Although this makes it seem that register in place is not supported, that is not likely the issue. The issue is probably a bug in the activation path.
The troubleshooting has turned into finding out what happened in your specific case that led to improper token creation. I'm following up with the activation folks for investigation ideas. RDP access would be great! I'll follow up with you when I hear back from them.
Thanks, Matheus
riverar
commented
1 year ago Perfect summary, thanks. I'm on the same page now.
riverar
commented
11 months ago @macruzco Any updates?
macruzco
commented
11 months ago @riverar I've followed up with activation and they pointed me to the source for package instantiation. I was working on reproing it locally when I got sidetracked by other work. I should be able to get back to it in the next two weeks. Apologies for the delay.
macruzco
commented
10 months ago Update: Getting back into it, EarTrumpet activates correctly on my end and has default access to the register in place directory as expected. I'll close this feature-request as register in place is already supported, and I'll file an internal OS bug to track the inconsistency I observed in the trace files for your specific VM to investigate what in the activation stack may be causing the issue.
Summary
It appears
isolatedWin32-accessToPublisherDirectorydoes not work for packages that are registered in-place withAdd-AppxPackage -Register path/to/appxmanifest.xml. Or perhaps sub-directories?AppManifest.xml snippet:
Summary.txt snippet:
Pitch
Visual Studio debug loop for packaged applications utilizes in-place registration. It is too cumbersome to fully package and deploy an application for debug/test scenarios.