"Job" objects allow some resource limits to be applied to groups of processes (including any children they spawn) but don't do much or anything for restricting the system resources accessible to process in a job.[1] Instead that is a feature called "silos"[2][3][4], as well as the accompanying use of Windows Brokering File System filter driver[5] (or is it UCIFS, or BFS+UCIFS...?[4]), as well as SeAccessCheck interception[6], and whatever else applied to a "silo" or processes.

Hardly anything about "silos" and seemingly nothing about BFS (for providing a virtual filesystem to a process) is documented publicly by Microsoft. Unless a Windows application developer has a particular interest in reverse engineering the Windows Kernel, they're probably not going to be using much of Windows Kernel sandboxing/isolation techniques beyond the simple interface that UWP exposes for GUI applications because it's just too hard otherwise.

For example, in the excellent description of this officially undocumented mess at [2] and [3], the author notes:

"What is interesting here is that there does not seem to be any general mechanisms for restricting access to syscalls globally, which means that the attack surface can be quite large. Indeed, even if it is possible for the Kernel to know if the execution comes from inside a Silo, each syscall must set up its checks (or not). In addition, some syscalls do not directly block access to Silos, but rather implement a different logic between a host and Silo context."

Another author at [4] finds all sorts of unexpected behaviours from this complex use of call interception, filter drivers, etc, such as endpoint security software not being aware of silos and use of filter drivers like BFS, etc, and not properly restricting or logging activities of "sandboxed" processes as developers and users of endpoint security software may expect.

Even if someone reverse engineered an adequate understanding of silos and whatever else Microsoft call "Process Isolation", they'd also potentially have to then learn the completely different Hyper-V isolation approach, as well as Mandatory Integrity Levels (MILs), as well as old school Windows ACL permissions, as well as the newish "Virtual Secure Mode" (VSM)[7]. It'd be like setting up a Linux system that has every Linux Security Module (LSM) enabled at once because SELinux is just too simple on its own.

[1] https://learn.microsoft.com/en-us/windows/win32/procthread/j...

[2] https://blog.quarkslab.com/reversing-windows-container-episo...

[3] https://blog.quarkslab.com/reversing-windows-container-part-...

[4] https://www.deepinstinct.com/blog/contain-yourself-staying-u...

[5] https://ht3labs.com/Brokering-File-System-January-2025-Patch...

[6] https://learn.microsoft.com/en-us/windows/win32/secauthz/imp...

[7] https://github.com/tpn/pdfs/blob/master/Battle%20of%20SKM%20...