1

I'm trying to use CreateAppContainerProfile to run a .NET 6 application. Based on the documentation that api is used to set up the same kind of sandbox used by UWP applications.

Now this works correctly if the application is installed below c:\program files but if it's installed elsewhere the process fails with "Failed to resolve full path of the current executable [path to the executable]" (code 0x80008085)

If the user account has the WRITE_DAC access right to the application folder I can allow the sandbox read/list_directory access and it works again, but if the user account itself only haves read/list/execute rights there I can't do that.

The documentation for UWP sandboxes say that they implicitly give the sandbox read access to the application directory (which makes sense) and considering the application works in c:\program files without granting any permissions, that seems to somewhat also apply here but I don't understand why it doesn't work the same elsewhere. Is there some security settings on the folders outside the user rights that would be relevant here?

There is so little documentation on this functionality I'm not entirely sure where else to look for information.

IInspectable
  • 46,945
  • 8
  • 85
  • 181
Tannin
  • 488
  • 5
  • 11
  • 2
    I haven't looked closely, but [Fun with AppContainers](https://scorpiosoftware.net/2019/01/15/fun-with-appcontainers/) may have a few bits of information that allow you to understand what's going on, or how this technology is intended to be used or what the technological limitations are. Unfortunately, for anything new(-ish), Microsoft's documentation showcases a severe lack of conceptual coverage. – IInspectable Jul 27 '22 at 14:50
  • Thanks! I did read that article though it doesn't really explain my problem - actually I'm fairly sure the article is partially incorrect/misleading. The way it describes it, the reduced access comes from processes having "low" integrity level but I can start a process with integrity level "low" directly - that has more permissions than the app container (and more than I want to allow). – Tannin Jul 27 '22 at 15:24
  • Have a look at [the question](https://stackoverflow.com/questions/59574479/is-there-any-way-of-ipc-between-appcontainer-process-and-normal-process-in-windo) which runs an application in Windows AppContainer successfully. And According to [Implementing an AppContainer](https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer), It's needed to manage permissions using *AppContainerSID* and *CapabilitySID* for AppContainer processes. – YangXiaoPo-MSFT Jul 28 '22 at 01:51
  • Here's a sample project using C# to sandbox a regular app in an AppContainer: https://github.com/ificator/ManagedSandbox I am not sure if the low IL processes you mention are the same as the low IL processes started in an AppContainer. I assume the behaviour is highly specific to the application you want to run - I'm sure most applications just assume at least medium integrity and don't cover special cases that crop up when running low IL. You didn't specify what application you tried, nor how you created the Container, so it's hard to tell what's going wrong. – Lennart Jul 28 '22 at 10:37
  • I've used both these sources as a basis for my implementation and as I said: my appcontainer does work, it's just that it doesn't have read access to the application directory outside c:\program files and there is no capabilities flag (it's supposed to be automatic after all) to affect that and to grant it manually would require elevated rights for the host process which kind of defeats the purpose. EDIT: I'm not sure how it'd be specific to the application, my problem is that I don't see any options to configure it to my needs and I can't imagine my requirements are unusual. – Tannin Jul 28 '22 at 11:13
  • As [Implementing an AppContainer](https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer) said, *so that all legacy, unmodified access control list (ACL) objects block access requests from AppContainer processes by default, and re-ACL objects that should be available to AppContainers*. How do you determine **application directory**? And Maybe you can try [Known Folders](https://learn.microsoft.com/en-us/windows/win32/shell/working-with-known-folders) for the application. – YangXiaoPo-MSFT Jul 29 '22 at 01:23

1 Answers1

0

Answering my own question here: I did really overthink this by assuming that the app container was supposed to magically give read/execute permission to the application directory.

In reality, c:\program files simply has an ACL for the special user "ALL RESTRICTED APPLICATION PACKAGES" that grants all app containers read/execute access to the entire directory tree.

Unfortunately this means there isn't really a nice solution for what I'm looking for apparently. At some point my main process has to be elevated to change ACLs to the application directory so that the app container can read it, there is no way afaict to just "inherit" rights the host process has to the containerized one.

"Capabilities" can be used when creating the appcontainer to allow access to certain predefined functionality (libraries, devices, ...) or you can basically set up custom capabilities, like a set of directories a container should be able to access but that then again requires the right to change ACLs on those directories when setting up the capability.

Tannin
  • 488
  • 5
  • 11