We know AppContainer provides a sandbox for store apps.
But what does it exactly do?
Also is the sandbox it provides configurable?
But what does it exactly do?
Also is the sandbox it provides configurable?
Windows AppContainer Isolation - what it does?
- Thread starter notabot
- Start date
Please provide comments and solutions that are helpful to the author of this topic.
It basically isolates those programs from the OS to help prevent the OS from being compromised from un-patched vulnerabilities. I believe Edge does/can make use of it as well. Chrome AFAIK takes advantage of it and the new sandbox for WD is based off it as well, so I think it's not solely tied to store apps. AFAIK it's not configurable, but someone with more knowledge can confirm or deny this. I believe that MS is the only one that can make changes to how it functions/works. I think it's up to the developer of a program to take advantage of it. Users cannot add any program to it manually AFAIK.
- Mar 29, 2018
- 8,062
I believe you are correct @Raiden. Yes, Edge also has its own container, and this is the main reason it is secure. Aside from the lack of user market share, which = it is probably not as big a target. Both good reasons to use it, if you can stand the privacy issues and the lack of extensions - still, after all this time. Especially well suited for PDF viewing, security -wise. I for one like it, and use it to compartmentalize my browser habits. I hope they retain the basic look and feel when they move to Blink engine.
My understanding is the same, at dev time sandbox parameters can be determined, I haven’t seen anything that indicates the existence of runtime configuration but maybe it exists and but it’s hard to find documentation for it ?).
What is the isolation though, does it mean that the sandboxed program is protected from injections ? Does it protect other processes from the sandboxed program ?
I think it’s not about 0day Protection but about mitigation, the exploited program will be more contained (that’s the case eg for Docker containerisation in Linux )
Eg in Linux each sandbox sees its own kernel namespace, it’s cant even see processes/threads on the host OS exist and for filesystem it can only see what has to explicitly be mounted at load time. I don’t have the same level of understanding with respect to what AppContainer does.
Last edited:
- Dec 23, 2014
- 8,970
AppContainer sandbox is based on isolation, but not on virtualization. It is intended to isolate the applications via: Credential Isolation, Device Isolation, File Isolation, Network Isolation, Process Isolation, Window Isolation:
AppContainer Isolation - Windows applications
WindowsInternals – Pavel's Blog
The standard desktop applications cannot run in AppContainer, but can be adapted to do it.
Application in AppContainer can create child AppContainers to run processes with different capabilities.
https://i.blackhat.com/eu-18/Thu-De...wser-Security-From-People-Who-Owned-It-wp.pdf
Capabilities define what is allowed to do by the application, outside of AppContainer sandbox. If the application requires to do something with higher (than Low) privileges, then it has to run a Broker.
AppContainer capabilities can be configured partially by external tools like:
M2Team/Privexec
There is a thread about it:
Privexec - Run the program with the specified permission level
AppContainer Isolation - Windows applications
WindowsInternals – Pavel's Blog
The standard desktop applications cannot run in AppContainer, but can be adapted to do it.
Application in AppContainer can create child AppContainers to run processes with different capabilities.
https://i.blackhat.com/eu-18/Thu-De...wser-Security-From-People-Who-Owned-It-wp.pdf
Capabilities define what is allowed to do by the application, outside of AppContainer sandbox. If the application requires to do something with higher (than Low) privileges, then it has to run a Broker.
AppContainer capabilities can be configured partially by external tools like:
M2Team/Privexec
There is a thread about it:
Privexec - Run the program with the specified permission level
Last edited:
Thanks Andy - just to clarify that other containerisation technologies eg Docker does not require virtualization either when the host and guest OS are the same, eg you don’t need virtualization to run a Linux guest from a Linux host. But of course if host is Windows and the Guest Linux, then there’s no other way but to use virtualization.
If host OS is the same as guest OS, just kernel namespaces are used
- Dec 23, 2014
- 8,970
Other sandbox solutions (Sandboxie, Comodo Sandbox, etc.) use isolation + virtualization for the extended protection. If the application is running in AppContainer then some changes are done in the real system (saving files, Registry modifications), they are not virtualized. The lack of virtualization makes also the AppContainer more vulnerable to malware attacks.
In some way the AppContainer is not a "true" sandbox, such as the Windows sandbox which will be introduced in the forthcoming Windows compilation. This new sandbox will adopt isolation + virtualization, when using the host system resources (no need to install the second OS).
Last edited:
does AppContainer then block both injections to the AppContainer’d process and injections coming from the process due to credentials isolation and process isolation ?
- Dec 23, 2014
- 8,970
Mostly the second kind. You have to use Exploit Protection to protect Applications in AppContainer against the injections from outside..
In general yes but Eg for DLL injections in specific, I’m not sure how it works in Windows but I’d expect a process that runs with credentials no other process has, to block dll injections (other than load time dll injections) from processes with the same privileges due to credentials - is this not the case ?
- Dec 23, 2014
- 8,970
Sorry my friend, I completely do not understand your post.
I am afraid that AppContainer has little or nothing to do with credentials. For simplicity, let's do everything on default Admin account. The processes with Low, Medium and High integrity levels can run on the same account. AppContainer uses Low integrity level + some additional read/write restrictions.
Last edited:
- Mar 13, 2016
- 1,298
Higher level Integrity rights objects can manipulate lower integrity level objects. Objects of same level also have access to each others resources,, so only with MemProtect like programs it would be possible to protect AppContainer programs against DLL-injection (because AppCointainer is the lowest Integrity Level).
My Guess is that this is the reason Microsoft uses a RunTimeBroker for Edge. This RunTimeBroker might protect Edge (in future?) against its environment against some attack vectors.
My Guess is that this is the reason Microsoft uses a RunTimeBroker for Edge. This RunTimeBroker might protect Edge (in future?) against its environment against some attack vectors.
- Dec 23, 2014
- 8,970
RunTime Broker is generally used by most Applications in AppContainer to perform the operations which require the privileges higher than AppContainer (reading and writing user files, accessing the clipboard, accessing services, etc.). RunTime Broker in Edge runs with medium integrity level, so it cannot be used to protect Edge. It can, for example, create child AppContainers in Edge. The Brokers can be exploited for privilege escalation.
Microsoft Edge uses Module Code Integrity enforcement via the kernel (CIG). That prevents injection of DLLs, except Microsoft-signed, or WHQL-signed.
Last edited:
Sorry my friend, I completely do not understand your post.
I am afraid that AppContainer has little or nothing to do with credentials. For simplicity, let's do everything on default Admin account. The processes with Low, Medium and High integrity levels can run on the same account. AppContainer uses Low integrity level + some additional read/write restrictions.
What I want to say is that for dll injections in specific, if the AppContainer runs under different credentials a standard user account should not be able to inject as I) the SUA is not the owner of the process II) it’s not a privileged account - is this not the case and injections to the process can only be protected using Exploit Guard ?
- Dec 23, 2014
- 8,970
If you start the application in AppContainer from SUA with user name 'NOTABOT' then the application runs on this SUA. Every standard user process running on this account (user 'NOTABOT') can inject DLL to this application. See for example:
Francesco149/uwpinject
Then agreed, nothing in AppContainer can prevent dll injection to the App then - I thought AppContainer run apps under different credentials ( with same privilege level but different nonetheless)
Exploit Guard it is then
From what @Andy Ful is explaining about the not-true sandbox, this looks same like McAfee dynamic application containment - the process of putting an executable in a clone of your OS and hardware is called virtualisation. The process of executing in real environment, but with “borders around it” is called containment.
You have certain pre-defined limitations (at least in McAfee DAC) but there are ways around them.
Additional technologies are needed to make sure that contained apps are completely disarmed, and not just slightly limited.
This is not be mistaken neither with a true sandbox, nor with cloud containers, where you have real hardware with several virtual boxes and every virtual box runs several containers.
Hope that makes it a bit easier to understand.
You have certain pre-defined limitations (at least in McAfee DAC) but there are ways around them.
Additional technologies are needed to make sure that contained apps are completely disarmed, and not just slightly limited.
This is not be mistaken neither with a true sandbox, nor with cloud containers, where you have real hardware with several virtual boxes and every virtual box runs several containers.
Hope that makes it a bit easier to understand.
Last edited by a moderator:
Similar threads
