And, to be fair, so is every other software project with an imperfect track record, that continues to have users, whether FOSS or closed source.
On Linux, yes you can spend months modifying Flatpaks, or writing SELinux rules or apparmor profiles but nobody does that. The out-of-the-box Linux user distros are quite a bit lacking and it is only a matter of time that malware that steal secrets from home directory to arrive to Linux too.
For what it's worth, RHEL and to some degree Fedora do give you those SELinux rules for most of their packages. That OOB for anything you would install with rpm.
> it is only a matter of time that malware that steal secrets from home directory to arrive to Linux too.
No need to wait? Most of the malware distributed over npm/pypi has supported Linux and sometimes MacOS for a long time.
I'm typing this on a computer that came with Windows 11. I booted it a few times, and reserved a terabyte of my (8TB) SSD for it, but I never use it at all. I've got some Windows VMs, from XP through 10 that I rarely use, but I use them when needed for things that require those platforms.
I got an email from Intuit two weeks ago informing me that they weren't going to support Windows 10 anymore, so I guess I'll be deleting my Windows 10 VM soon, but I have no intention of ever creating or running a Windows 11 VM, or installing anything important on the soon-to-be-deleted Windows 11 partition I have, so I guess I'll quit using TurboTax after 40 years of using it.
I looked into the possibility of running TurboTax with Wine (or CrossOver, for which I have an eternal license), but apparently it doesn't run at all there.
Because there are obvious architectural limitations of having a linear scale of privilege levels which one places all processes on, Windows has tried implementing "Windows Sandbox" as an alternative sandboxing mechanism that executes a process in a Hyper-V virtual machine that has restrictions placed on the interfaces exposed into the virtual machine.
I believe Windows Kernel still doesn't have any similar functionality to Linux's namespaces that are much more capable and flexible with sandboxing applications. The reason I recall is Windows' GDI subsystem (painting/drawing) being implemented within the Windows Kernel, not a userspace process as you see with Wayland compositors on Linux systems. This GDI subsystem I believe was the main problem holding back the Windows Kernel from implementing Linux-like namespace and sandboxing functionality.
Linux and common desktop environments such as Gnome also offer sandboxing out-of-the-box in more ways than a typical Windows installation, including as examples:
- very granular seccomp filters implemented for system processes (typically via the simple and accessible method of systemd service configuration) to only permit a process to make certain syscalls or access only specific system resources (files, network interfaces, etc)
- seccomp filters for revoking permissions on processes once they've started up and no longer need certain permissions. See for example OpenSSH and how it forks into less privileged processes once ports have been opened, keyfiles read, etc.
- Use of multi-process application architectures where each process is individually sandboxed, where a Windows equivalent would be a monolithic application. See for example use of "glycin" in Gnome applications for parsing and loading images in separate sandboxed processes from other parts of the application[4], or "tracker" again in Gnome applications which sandboxes the processes for metadata extraction from each file.
[1] https://learn.microsoft.com/en-us/windows/security/book/appl...
[2] https://learn.microsoft.com/en-us/windows/apps/windows-app-s...
[3] https://learn.microsoft.com/en-us/previous-versions/dotnet/a...
[4] https://gitlab.gnome.org/GNOME/glycin
edit: some references added
It predated https://github.com/sandboxie-plus/Sandboxie but Sandboxie is an example (from 2004) of a similar project that has a longer development history. There have been other similar projects that have come and gone over the years too.
Nowadays serveral kernel services and drivers are virtualized, running inside Hyper-V instances.
Some of the Windows 11 hardware requirements is that all optional virtualization and sanboxing security features are no longer optional.
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...