Microsoft rewarded for security failures with another US Government contract

Microsoft is rewarded for security, privacy and reliability failures each time a consumer buys another Windows PC.

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.

I don't use Linux as my primary OS anymore. However the default protections of the Linux desktop is worse than Windows's which is rather sad. For "root" level operations Windows has several layers to protect the system itself. The newer Appx packages are have scoped security protections around them.

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.

Windows has AppContainers which is for the most part a wrapper around the Windows Kernel Mandatory Integrity Level (MIL) feature.[1][2] MIL restricts certain API calls of processes depending on the integrity level of the current process vs. integrity level of a target process for the API call. The idea being a process with a low integrity level wouldn't be able to read or write via IPC to a process with a high integrity level. The process with a high integrity level would instead need to read or write via IPC to the process with a low integrity level.[3]

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

Just to add a bit of history--there was a little known software product, a name which I cannot remember or find, in the early 2000s for Windows NT based operating systems, which hooked API calls of Windows applications to implement seccomp-like filtering for random Windows applications. I recall it allowed users to restrict an application to not perform certain system actions, access certain folders/files, etc. It was well ahead of its time for early 2000s operating system hardening and I think may have been an inspiration arising from early 2000s rootkits.

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.