Overview

Madaidan the self-proclaimed wannabe security researcher ala Wikipedia copy-and-paste, spreads a lot of nonsense about things he obvious has no clue about because it is way above his head which is directly indicated with the weak examples he presents. So, time to fire back to debunk the one who claims to debunk others. Oh, I will give you Wikipedia links in mass, if that is your style buddy. Now that you fake reported me, I have some time, I always wanted to debunk your nonsense but this is the perfect opportunity to put an end to all of this.

First of all let me explain that the world is not just black and white and the final conclusion is not that Windows is more secure or that Linux beats Windows, it depends on variables and factors that I present below. During the explanation I will also debunk false claims from Madaidan that exposes him to have absolute no actual real-world expertise on his own presented topics.

His text is available over here. I review the latest version, as of time writing my article and comments, his last edit was March 18th, 2022.

I link the original article, and use the fair use principle to quote the parts in order to make it easier to follow the given text and to avoid switching between both articles. However you are absolutely encouraged to open both sites side-by-side and inspect his claims and my small article here. I quickly wrote this together in one night, so I absolutely will update and change several parts.

The text is still unfinished until I remove this line and absolute not ready to be shared, please respect my wish and do not re-post it until I permit it because this here is not a final version. Thanks.

Lets get him and put and end to his nonsense he spreads - His Introduction

Linux being secure is a common misconception in the security and privacy realm. Linux is thought to be secure primarily because of its source model, popular usage in servers, small user base and confusion about its security features.

Absolute no backup for any of this, this is your opinion about what others might think it is, it is no misconception rather perspective based on examples, experiences and usability. No one except you imply anything like that and no one can ultimately proof which system actually is more secure because some security aspects heavily depending on user experience, knowledge and things that the operating system cannot directly positively influence such as getting social engineered to expose something that the best security system cannot protect you from. There is simply no operating security mechanism that protects you from certain attack scenarios and unless you are aware of it you only then can begin to start counter measurements. Lots of things can be prevented in the first place which you simply do not mention at all, skills, knowledge precautions are crucial and mandatory if we talk about overall security. You basically always assume directly, for whatever reason that the user is stupid enough to infect himself in the first place with some unknown or super sophisticated attack scenario, this is rarely the case, in most cases attackers using well-known techniques that quickly can be covered, blocked in the first place with the simple awareness of it, which means even if your system would be vulnerable the user might never fall of it and execute malware in the first place. Prevention is the keyword.

Small user base does not imply less of an attack target especially not with WSL in mind because it opens up a lot more attack vectors that both Windows as well as Linux users can experiment with.

This article is intended to debunk these misunderstandings by demonstrating the lack of various, important security mechanisms found in other desktop operating systems and identifying critical security problems within Linux's security model, across both user space and the kernel. Overall, other operating systems have a much stronger focus on security and have made many innovations in defensive security technologies, whereas Linux has fallen far behind.

Nonsense. No backup for such a claim. It is bullshit, Linux also implemented lots of counter measures, as listed here. It quickly adopted to serious security problems like Spectre. On some Windows you had to install patches manually because Windows Update did not offered any Microcode-Update at all and the user is forced to manually download the .msu package and install it. We are not even need to mention that BIOS - UEFI wise vendors also typically take months to release new updates, or people are not aware of updates because Windows has no system to notify users about new BIOS that they can install. So the awareness is more worth than a theoretical model you might want to cover here.

According to user share statistics Windows is the most used OS, overall spoken. More users, more interest, more theoretical attacks because mainstream and interest in infecting beginners is much easier, this is pure statistics.

Section 1 explains the lack of a proper application security model and demonstrates why some software that is commonly touted as solutions to this problem are insufficient.

The code complicity is not even mentioned which is considerable a security factor, we are still in the intro and I debunked 3 lies already.

Sandboxing

The first link he posts is from 2010, claiming it would be the traditional security model, whatever that means is unclear. Windows had not even any Hyper-V or Sandbox layer at that time, which you later refer to as claim for more security. Security btw has no models what you mean are policies under a scheme, however concept and scheme constantly evolves, and overall the term models are only mentioned or referred too in order to make it more comparable about what basis and ground we are talking about. What he meant is Stride. At best you can categorize, model and adopt + respond to threats.

Sandboxing does not protect against

• Already infected VMs and infected containers, you still can be infected or already compromised.
• Assuming an attacker has access and took over, sandboxing is a huge problem because gaining control is considerable harder, getting back your container, data etc is almost impossible or only with huge effort.
• Getting infected in the first place.
• Leaking credentials insecurely stored and transmitted via command and control.
• Microarchitectural attacks have been greatly explored over the last years, there are a lot of news regarding this matter, for example. Those attacks can have a great impact on security by allowing attackers to circumvent system isolation.
• Parts of Windows applications as well as kernel related things are not sandboxed, depending on the OS Build, which applications and if Hyper-V is present or not.
• Social engineering to obtain security critical information such as SSH keys, or similar stuff that can render you vulnerable to start other attacks.
• The sandbox must be manually started to test new stuff, it does not cover the already running OS, assuming you not already sit in a session that runs within a sandbox.
• Escape scenarios are possible

This means that any malicious application you install or an exploited vulnerability in an otherwise benevolent application can result in the attacker immediately gaining access to your data. Such vulnerabilities are inevitable, and their impact should be limited by strictly isolating software from one another.

No, there exist malicious applications that cannot look into other partitions without higher privileges and permissions. In order to be “malicious” the malware has to be executed, and that is done by the computer/CPU, not the disks, besides that it needs - as mentioned - permissions and a permission model is not sandboxing. A layered approach without sandboxing to protect your storage is setting up basic encryption, counter measures are explained a bit below.

Linux still follows this security model, and as such, there is no resemblance of a strong sandboxing architecture or permission model in the standard Linux desktop.

Some Distros come directly with AppArmor, Seccomp, Docker containers and device permissions that contain policies to run in isolated sandbox. Linux seccomp is a bit ore modern approach that can even isolate foreign and unknown proprietary applications. Windows Defenders own sandbox is also far away from perfect.

current sandboxing solutions are either nonexistent or insufficient. All applications have access to each other’s data and can snoop on your personal information

Containerized images can include a bunch of kernel security features (SELinux / AppArmor, unshare, chroot, etc) to isolate a process without the overhead of a VM. The most easiest way are containers because they can not access either processes or containers on the OS level, each one has an individual process namespace, you also can combine it with a chroot jail to strengthen it further.

Windows still falls behind when it comes to sandboxing, but it has at least made some progress — Windows automatically sandboxes UWP applications and provides the Windows Sandbox utility for non-UWP applications.

Most people do not run UWPs because it depends on several requirements that some people dislike, like the Store, Microsoft then later added support to run the UWPs without additional requirements, this was added after complaints and was not Microsofts first choice, you anyway need to trust Microsoft which is controversial on its own. Actually people including myself hate UWP. UWP based games also got cracked even with multiple layers, the more security claim is debunked already at this point.

Not sure why he mentioned macOS and ChromeOS at this point, topic is Linux vs Windows. Maybe he mention macOS to pretend he knows something about it,...

Flatpak

He links to FlatKill.org which is debunked over here, the discussion about the website that includes misleading nonsense is in-depth discussed over here.

He forgets to mention that some Distros do not enable Flatpak by default, once again this depends on variables such as what Distro we are talking about and their default settings, some disable it, some remove it entirely. I personally do not use it. Never did, and prefer AUR.

In the Flathub Github organisation, ~550 applications come with such permissions, which is ~30% of all repositories. While this percentage may not seem significant, it includes a considerable amount of applications that people will commonly use. Examples of such include GIMP, Eog, Gedit, VLC, Krita, LibreOffice, Audacity, VSCode, Dropbox, Transmission, Skype and countless others.

How many of these applications got exploited successfully and attacked millions of potential users. An attack is not automatically successful just because you use a weak app or permission model. This depends on the malicious app and about what malware family we are talking about. Madaidan lists here zero examples and not every CVE gets exploited in the wild or is reliable because it depends on other factors.

Another example of Flatpak's broad permissions is how it allows unfiltered access to the X11 socket, permitting easy sandbox escapes due to X11's lack of GUI isolation. Adding X11 sandboxing via a nested X11 server, such as Xpra, would not be difficult, but Flatpak developers refuse to acknowledge this and continue to claim, "X11 is impossible to secure".

Again, permissions alone do not equal a successful attack. The irrelevant X11 link is from 2015 and some Distros run Wayland. DWM on the other hand is also vulnerable and easily exploitable, what is the point here, that you locally can exploit something or do you want to talk about sandbox escapes, that occur regularly on Windows.

Further examples include Flatpak giving complete access to directories such as /sys or /proc (kernel interfaces known for information leaks), rather than allowing fine-grained access to only the required files, and the highly permissive seccomp filter which only blacklists ~20 syscalls and still exposes significant kernel attack surface.

Big bummer, giving away data, how many malicious app you find in FlatPak repository I want to ask at this point and how many malware apps you find for Win32 and Ms Store.

Firejail

FireJail is not preinstalled on most Distros, once again this argument depends on variables, variables that the user or the Distro developer must decide to integrate or not. The rest is up to the user, think it is insecure, than do not install it. What is the point showing here alternative approaches that depend on user or developers opinion and freedom to install or not to install it, on Windows you have only once choice the one that Microsoft offers.

Firejail is another common sandboxing technology

No, since you cherry pick ever word, keyword pish, this is not accurate, it is a SUID sandbox program and not a technology. It utilize application based sandbox technology, this is a difference because there exist several actual technologies to sandbox that work different, on hardware level, container etc. If you nitpick, I nitpick back. I guess your point is overall do not use Firejail, yeah sure and I say do not use sandboxie it is also slow, outdated and replaced with hardware vitalization.

You list years old programs and techniques and compare it against a considerable new or improved Windows 10, how cringe is that. If I compare it against XP or older system from the same time this was invented then who look more secure, sure as hell not Windows. God is this argumentation low, and so unrealistic, if you security oriented you typically use the latest programs, systems and virtualization techniques that the OS offers, how many Distros pre-install Firejail today...

Then you mention a new program, bubblewrap, yeah, but your point is what exactly that a new program that was coded as replacement or alternative might fix stuff or introduce less attack surface, what is the news here. I guess your point is you have none and want to look smart, still irrelevant to Windows because on Windows you have VMs, Sandboxie or Microsofts solution which is based on Hyper-V as upper layer. Stuff that depends on the actual Windows SKU e.g. Home Edition have no Hyper-V support or depend on hardware support, older hardware might never be able to utilize it or Microsoft blocks the installation of specific - old - hardware entirely.

Unfortunately, bubblewrap isn't very widespread and can be difficult to learn. Bubblewrap is essentially a bare bones wrappers around namespaces and seccomp. A user would need decent knowledge on how the filesystem, syscalls and so on work to properly use it.

Yeah and cola with Kiwi is also a nice cocktail recipe. Cringe man, irrelevant to the Linux vs Windows argumentation. We all know that outdated technology has problems, you just respell the same naming example and cherry pick this as evidence that Linux is less secure, lame, nonsense and unprofessional. Fun fact, do not use Windows ME. Same argumentation structure and logic. In the real-world your nonsense does not hold because upgrades are not easily approachable it often depends on factors such as current running system, is it upgradable, money, attack surface as well as what the environment has for specific conditions. You assume the world is deal but this is not the case.

Exploit Mitigations

Exploit mitigations eliminate entire classes of common vulnerabilities / exploit techniques to prevent or severely hinder exploitation. Linux has not made significant progress on implementing modern exploit mitigations, unlike other operating systems.

No proof that Linux made no - whatever significant means - progress, it is pure horseshit. Ransomware used by cyber-criminals typically target Windows PCs because the target is bigger, more PCs running the same OS makes it attractive for criminals. Linux is less affected by ransomeware, which does not mean there exist no RM for Linux, but due to the nature the OS works typically less is gained from it. Isolation or not does not protect against Ransomware on Windows. Typically the malware is delivered with phishing trough e.g. eMail attachents, preventing phishing is according to latest observations mandatory. The knowledge and awareness usually prevents the attack surface already. Overall multiple layered-strategy is preferable and not only one technology in case someone breaks trough.

The claim that Linux has not made significant progress is a bolt claim, that does not withstand, new attacks are typically quickly mitigrated, de facto Windows made, according to your logic more progress because older Windows systems had absolute no or weak techniques implemented, therefore they addressed this in newer Windows versions as a result of constant attacks. The logic here to claim that this is significant process or more than Linux because older operating systems are weak as hell is unprofessional comparison.

Most programs on Linux are written in memory unsafe languages, such as C or C++, which causes the majority of discovered security vulnerabilities.

Same like on Windows, claiming Linux is less secure based on decision a developer has to make is unprofessional and an retarded argumentation logic. You can use Rust the same way on Linux like you would do on Windows, the tools, docs etc are all provided and documented.

Other operating systems have made more progress on adopting memory safe languages, such as Windows,

NO, your argumentation continues to be retarded. Just because Microsoft announces something does not mean it is overnight all changed and switched, Torvalds pointed this out that there are problems with Rust. You tell once more pure nonsense, because no slightest research was done. Switching to more secure languages from old systems is not done after the announcement, it takes maybe years, because Microsoft will also suffer from repercussions based on the fact that it is not easily be changed, you need to address certain problems that Torvalds pointed out, there are also other things that need to be done, backward compatibility which can be challenging because Windows contains 20+ years old code in the OS, leftovers and there is the unsolved Win32 vs UWP mess problematic.

While Windows and macOS are still mostly written in memory unsafe languages, they are at least making some progress on switching to safe alternatives.

Same like Linux, you clown.

The Linux kernel simply implementing support for Rust does not imply that it will be actively used.

Same like with the Microsoft announcement which I explained above, the process is not immediately like an on and off switch. Rust lands in Kernel 5.20.

Only a handful of drivers are going to be written in Rust, which will actually result in a net loss of security, as mixed binaries can allow for bypasses of various exploit mitigations.

There are variables such as speed. The link for mixed binaries problematic, points to Browsers, not the Kernel other topic, as the Browser does not run at lower levels and is therefore theoretically more vulnerable if you want to compare problematic language based criticism regarding security. Your loss of security is only theoretically since you do not provide any evidence, real-world scenario or attack vector on which your claim is based on.

Microsoft is the only vendor to have solved the aforementioned problem by implementing Control Flow Guard support for Rust.

What you mean is Shadow Stack (SS) and Indirect Branch Tracking (IBT). CFG is not in regard of mixed binaries security.

Linux uses Reuse attack Protector (RAP) or control flow integrity (cfi), see here for a presentation.

Furthermore, modern exploit mitigation, such as Control Flow Integrity (CFI), are also not widely used on Linux. A few examples are explained below; however, it does not attempt to be an exhaustive list.

Nonsense, besides why should Linux adopt every new gimmick Windows does, how is that related to security, it depends on implementation and what exactly you use. Linux works different than Windows and the entire logic falls apart then trusted apps run already in secure namespace.

Arbitrary Code Guard and Code Integrity Guard

Wants to pretend he is smart, trying to explain us how to go to the toilette. I think everyone knows in the security scene what Arbitrary Code Guard and Code Integrity Guard is designed for, come to the point. The introduction is irrelevant. It does not prove that Windows is more secure or preferable.

Return-Oriented Programming (ROP) or Jump-Oriented Programming (JOP)

Zero Cool, but wayne !? I guess you just copied something from papers to sound smart, Linux has ROP support. JOP is in general more vulnerable.

More blah what attackers do, code injection is as old as the Linux Kernel. Windows is not better against code injection.

Attackers do this and that - drink coffee - I think this is irrelevant nonsense info, you can harden Windows with just Simple Windows Harden utility or harden Linux with some scripts or by installing a hardened Kernel. You talk shit here and you know it, you even give examples that Linux also adopts new techniques contradicting your entire point that Linux is less fast in adopting new - significant - changes, whatever that means I suppose you expect that Linux copies and imitates every new security standard Microsoft includes or rewrite the entire Kernel or upper security layer each time, this is unrealistic and would break already existing systems. It can also be potential less secure because just because you introduce new features does not make them more secure, with more code complexity more potential attack vectors can occur.

Control Flow Integrity

Lets copy more from Wikipedia in the list, alrighty moving on. Most of those nonsense introduction are planted to sound smart and to pretend Madaidan has any clue, all of this is well documented on Linux and Windows end. No point at all listening it.

Again an introduction about what it is, we know it, why is that important and relevant for the claim Linux security sucks. If you want to know more about upcoming features or already implemented security features I highly suggest reading the Linux bible.

The Linux kernel has only implemented support for Clang's forward-edge CFI on ARM64, and in user space, any CFI is practically nonexistent outside of Chromium. In comparison, Windows has had its own coarse-grained, forward-edge CFI implementation since 2014, known as Control Flow Guard (CFG), which is used in the kernel and across user space.

Nonsense, implemented since Linux 5.14, the only drawback was that in 5.13 it was not finished. Besides your wrong statement there exist some bypass techniques already which was one of the reason, among implementation problems why it took a bit longer than anticipated.

Windows also makes use of Intel CET shadow stacks for backward-edge protection, and while CFG is only coarse-grained, Microsoft are working on making it more fine-grained with XFG. M1 Macs also use Pointer Authentication Codes (PAC) to ensure forward and backward-edge protection.

Cool that you copy it, would never be able to research it myself. The point here is what exactly, I suppose you want to talk about the reduced attack vector, this was reviewed and addressed in Linux.

There is no underlying point why you mention it at all, no conclusion or reference why Windows offers here more for ARM. No proof, just nothing, you just wanted to try to explain us how shit works. Pointless, you want to proof that Linux is less secure, which is nothing but nonsense.

Automatic Variable Initialisation

One of the most common classes of memory corruption vulnerabilities is uninitialised memory. Windows uses InitAll to automatically initialise stack variables to zero for the kernel and some user space code, as well as safer APIs for the kernel pool. Whereas on Linux, there are mitigations specifically for kernel stack and heap memory, but this does not cover any user space code, and most mainstream distributions don't actually enable them.

Mitigating Uses of Uninitialized Memory for Linux is advised and explained in this paper. In Linux userspace there is a system call mprotect that can modify the protection flags on existing mapping, this depends on what Kernel you use, with which flags and which Distro delivers them, that - most mainstream distributions do not actually enable them - is a claim without anything behind. First of all what is according to you a mainstream Distro, specify....

Virtualization-based Security

Windows supports Virtualization-based Security (VBS), which allows it to run the entire operating system inside of a virtual machine and is used to enforce a number of security guarantees. Examples of such include:

Virtualization-based Security bypass, here. Slow-downs reported over here.

Linux demonstration here.

Hypervisor-Enforced Code Integrity (HVCI) makes it significantly harder to inject malicious code into the kernel by using the hypervisor to strengthen code integrity guarantees and ensuring that all code must be validly signed. Even if an attacker has arbitrary write capabilities and can corrupt page table entries (PTEs) to manipulate page permissions, they will still be unable to execute their shellcode because the hypervisor that runs at a higher privilege level won't permit it. This can be thought of as similar to ACG but much stronger and for the kernel.

Basically copied from the official documentation that we all know, not coming to any point why Windows handles it better than Linux. [Windows has lots of shell based issues(https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-1286).

Alternatives to Hyper-V are Xen or VMWare ESXi, if you think Windows is more secure - based on unproven claims that you spread - then run Windows Subsystem for Linux. Hyper-V needs btw minimum Windows Pro or higher.

PTEs is addressed by now. Linux uses Kernel-self protection, more virtualization is explained over here.

PatchGuard is a feature that verifies the integrity of the Windows kernel at runtime by periodically checking for corruption of important kernel data structures. Although because PatchGuard runs at the same privilege level as a kernel exploit, an attacker could simply find a way to patch it out — historically, the only obstable to this has been heavy code obfuscation techniques that can make it hard to disable. However, with VBS, Microsoft have reinforced this protection with HyperGuard, which leverages the hypervisor to implement it a higher privilege level, thereby making it immune to PatchGuard's weaknesses and substantially more difficult to bypass.

More irrelevant copy and paste in attempt to explain us how a toilette works. SGX was implemented in Linux, there are also explanation and examples given. There exist several bypass techniques. Yet with all this, you still can quickly extract credentials. I guess you have no point here.

On Linux, there is currently no equivalent to VBS.

Wrong again there exist LKRG aka Linux Kernel Runtime Guard which is practical a KVM, which can be combined with Hooksafe. They work different but provide similar approach to Microsofts VBS.

Kernel

The Linux kernel itself is also extremely lacking in security. It is a monolithic kernel, which means that it contains a colossal amount of code all within the most privileged part of the operating system and has no isolation between internal components whatsoever.

No link, no documentation, no proof what Windows isolates here better, because whops, the Windows Kernel is not open source so on what reverse engineered samples is this wrong assumption based upon do not say ReactOS. I bet if you release Windows Kernel people would quickly expose the devastating condition of it, which happens often whenever Microsoft released some apps that were previously closed source some apps they had amateur code in it and the community fixed it.

The kernel has huge attack surface and is constantly adding new and dangerous features.

And Windows does not add new features right. Not sure if you are just a troll or someone who pretends to sound smart, possible both.

One example of such dangerous features is eBPF. In a nutshell, eBPF is a very powerful framework within the Linux kernel that allows unprivileged user space to execute arbitrary code within the kernel in order to dynamically extend kernel functionality. eBPF also includes a JIT compiler, which is fundamentally a W^X violation and opens up the possibility of JIT spraying. The kernel does perform a number of checks on the code that is executed, but these are routinely bypassed, and this feature has still caused numerous security vulnerabilities.

Jit also exist in Windows, you even can control and adjust the behavior. You can pwn the kernel with eBPF same like you pwn the Windows kernel. There are many many ways to pwn Windows, there is no point here. You can just use alternative frameworks. Nothing new. Microsoft later did indeed uses similar vulnerable eBPF JIT within the Windows Kernel.

Another example of these features is user namespaces. User namespaces allow unprivileged users to interact with lots of kernel code that is normally reserved for the root user. It adds a massive amount of networking, mount, etc. functionality as new attack surface. It has also been the cause of numerous privilege escalation vulnerabilities, which is why many distributions, such as Debian, had started to restrict access to this functionality by default, although most distributions eventually dropped these patches in favour of usability.

We had this already above, now he directly calls out namespaces. Namespaces an be configured to e.g. disallowing specific network policies. If you install apps from trusted sourced the entire namespace argumentation becomes null and void.

The endless stream of vulnerabilities arising from this feature shows no sign of stopping either, even after years since its introduction.

Has something to do with compatibility, Windows fights with kerberos without end in sight. You also find numerous privilege escalation vulnerabilities in mass in Windows.

The kernel is written entirely in a memory unsafe language and has hundreds of bugs, many being security vulnerabilities, discovered each month. In fact, there are so many bugs being found in the kernel, developers can’t keep up, which results in many of the bugs staying unfixed for a long time. The kernel is decades behind in exploit mitigations, and many kernel developers simply do not care enough.

He repeats himself now, this is duplicate, already addressed. Windows has minimum the same amount, no proof at all that Linux has more, I highly doubt that Linux community cannot keep up with security patching. This is baseless accusation and disrespectful against the ones who work in the community.

Other kernels, such as the Windows and macOS kernels, are somewhat similar too, in that they are also large and bloated monolithic kernels with huge attack surface, but they at least realise that these issues exist and take further steps to mitigate them. As an example of this, Windows has historically been plagued by vulnerabilities within its font parsing code, so in response, Microsoft moved all font parsing out of the kernel and into a separate, heavily sandboxed user space process, restricted via AppContainer. Windows also implemented a mitigation to block untrusted fonts from specific processes to reduce attack surface. Similarly, macOS moved a substantial portion of its networking stack — the transport layer — from the kernel into user space, thereby significantly reducing remote kernel attack surface and the impact of vulnerabilities in the networking stack. Linux, however, does not focus on such systemic approaches to security.

Why always the reference to other systems, you claim Windows is more secure than Linux and that Linux is insecure - according to your opinion -, stay with these two operating systems and do not bring others into the conversation. The statement - large and bloated monolithic kernels - is again re-spelled, there are pros and cons and not every systems uses such a structure. There are overall more pros and the negative aspects are often unrelated to malware.

Linux fixed font bugs and security issues, same like Windows that also was vulnerable, we actually had the case multiple times, over years and years.

Linux, however, does not focus on such systemic approaches to security.

• Windows also has problems with the network stack.
• Lots of CVEs, that reoccur because this is difficult to handle without breaking things.
• Elaborate why Linux does not focus on systemic approaches, this is nonsense without evidence.

The Nonexistent Boundary of Root

On ordinary Linux desktops, a compromised non-root user account with access to sudo is equal to full root compromise, as there are an abundance of ways for an attacker to retrieve the sudo password.

On Windows you can quickly obtain passwords too, compromised is compromised, does not matter if on Linux or Windows. There is no specification made here what compromise in that sense should imply, once you bypass UAC. On Linux you can simply limit the use of sudo.

Usually, the standard user is part of the "sudo" or "wheel" group, which makes a sudo password security theatre. For example, the attacker can exploit the plethora of keylogging opportunities, such as Xorg’s lack of GUI isolation, the many infoleaks in the procfs filesystem, using LD_PRELOAD to hook into processes and so much more.

Not the case with e.g. TailsOS and other Distros. On a compromised system pretty much all systems are weak against keylogging. See here, here and in general the keyboard API is not well protected.

Even if one were to mitigate every single way to log keystrokes, the attacker can simply setup their own fake sudo prompt by manipulating $PATH or shell aliases/functions to intercept the user's password, completely unbeknownst to the user.

This is still on an already compromised system scenario, which also applies to Windows. WPI is also easy on Windows.

While similar attacks are still possible on other operating systems due to the inherent issues in escalating privileges from an untrusted account, they are often much harder to pull off than on Linux.

Untrue. You can define specific rules in gpedit on Windows as well as in Linux with the integrated tools, on how passwords, accounts, logging etc is handled. Defaults are weak on both systems, that is correct.

For example, Windows' User Account Control (UAC) provides the secure desktop functionality, which can make spoofing it significantly harder, provided one is using a standard user account.

UAC bypass, defaults are vulnerable but not if you switch it to the max level. On Linux, if you want some font-ends you can use gksudo/kdesudo/pkexec. Some hardened distros come preinstalled with specific crafted tools making the user more aware of what is going on or what is requesting access.

Moreover, Windows better prevents keylogging by isolating processes that run at lower integrity levels from those that run at higher integrity levels, therefore mitigating Xorg-style attacks.

• Windows UI Accessibility Applications can be allowed bypass UIPI.
• Clipboard api is weak.
• Keylogging is easily possible via PowerShell, depending on what PS you use you are more or less affected.
• There is no keystroke protection, the line of defense here depends on Windows Defender.
• RubberDucky works on Windows protection here also depends on Windows defender as well as default settings vs hardened.
• You find keyloggers for practical every OS, however the success of it means that you already need to bypass certain security mechanism, need root etc.

Windows also restricts DLL preloading by disabling the AppInit_DLLs functionality when secure boot is enabled and providing a way to restrict DLL search paths, therefore also mitigating many LD_PRELOAD-style attacks. Similarly, macOS includes the secure event input feature, which thwarts many keylogging attempts and secures keyboard input. In addition, macOS' System Integrity Protection and Hardened Runtime features can also prevent LD_PRELOAD-style attacks.

• Windows dll side-loading is not full solved, see here
• Keystrokes via X11, some Distos do not come with X11 enabled by default.
• On lots of systems xorg-xinput is not preinstalled. The example then does not work. The security and examples once again depends on system configuration and if xorg-xinput is present or not.
• I think he stole the example or idea from here which is from 2015, lots of things changed since then.
• You can harden the sudo policies
• If the integrity of the file system is potential compromised, every OS at this point is considered insecure.

This technique is quite common and is used in the majority of user space rootkits. A few examples are azazel, Jynx2 and HiddenWasp.

Cool, same like Windows is also able to run rootkits, e.g. Cronos-Rootkit, Nidhogg, r77-rootkit.

Stable Release Models

A myriad of common Linux distributions, including Debian, Ubuntu, RHEL/CentOS, among numerous others use what's known as a "stable" software release model. This involves freezing packages for a very long time and only ever backporting security fixes that have received a CVE.

Most security fixes do not receive CVEs because either the developer simply doesn’t care or because it’s not obvious whether or not a bug is exploitable at first.

• Microsoft does not patch all security related things or it takes months, others need to step in and patch. Microsoft has a strict criteria on what falls under security patch management, it that does not fall in the requirements it will not be patched at all. It yet again depends on specific variables, how hard it is to exploit, if it depends on third-party involvement e.g. infection trough Browsers and so on.
• CVEs are no measurement instrument, not every CVE is critical, not everything gets attacked and some things might never made it into the CVE database. There probably exist security holes that are not disclosed yet, claiming here Windows is more secure is nonsense.
• Linked evidence that open source or Linux gets not fully patched is a deep neural-network-based approach, not everything the network find needs to be patched, it is here questionable if everything is security related and if such approach cannot be implemented directly on coding platforms, we already have bot systems on GitHub and GitLab. Microsoft also uses an ML system, however such things are by far - so far - not perfect.
• The release model can be changes, switched and the user can decide to use a rolling released based Distro. Entirely irrelevant for security too as we clearly showed that the CVEs do not equal insecurity and even stable release modals can get severe security patches in case of emergencies. His argumentation basis only relies on if the binaries need to be recompiled, some improved practices can improve the backporting approach.

Distribution maintainers cannot analyse every single commit perfectly and backport every security fix, so they have to rely on CVEs, which people do not use properly. For example, the Linux kernel is particularly bad at this. Even when there is a CVE assigned to an issue, sometimes fixes still aren't backported, such as in the Debian Chromium package, which is still affected by many severe and public vulnerabilities, some of which are even being exploited in the wild.

Not accurate, maintainer can utilize tools provided by coding tools, coding platforms and utilize machine learning systems or inspect the code trough automated systems. Microsoft uses it, I do not see why Linux could not use it too. I also doubt that every CVE from Microsoft gets analyzed, I think it is a mix between public databases, community feedback and finding as well as priority. The CVE level argumentation does not hold as CVEs are no absolute measurement instrument however it is interesting that you do not mention Microsoft because they do not disclose much details, so your claim cannot hold as you have no clue what Microsoft miss or only late patch except that wat is public disclosed.

Newer and faster patch management if not properly reviewed can lead to supply chain based attack scenarios, faster does not necessarily equals more security.

On Windows and properly on Linux there exist external third-parties like 0patch that can micro-patch unofficial programs that might not get any official support anymore. Within the community there are also groups that might patch specific software and release their backports that you or the Distro maintainer can quickly adopt. It is unclear, without examples how mainstream the claim is that sometimes real issues not going to be backported which could potential lead the system vulnerable. I think that is pure statistics talk.

Manual Hardening

It's a common assumption that the issues within the security model of desktop Linux are only "by default" and can be tweaked how the user wishes; however, standard system hardening techniques are not enough to fix any of these massive, architectural security issues.

There are tools, scripts for all systems, Linux and Windows. You also can use pre-configured hardened kernels and Distros. On Windows end you can apply patches via tools such as NTLite etc.

You will never patch or perfectly harden any system because it would destroy usability, performance and other stuff that the user might depend on. This goes vice versa. It is unclear what is meant with - standard system hardening techniques - and it is also not mentioned what exactly cannot be fixed because of the architecture. This is pure speculation, you only need to harden it to make the effort for an attacker so hard that he loses interest but I since no example is provided no one knows what standard here in this context imply. Hardware based attacks that require physical access, or malware drive-by attacks, ... It is not clear.

Restricting a few minor things is not going to fix this. Likewise, a few common security features distributions deploy by default are also not going to fix this. Just because your distribution enables a MAC framework without creating a strict policy and still running most processes unconfined, does not mean you can escape from these issues.

According to whom, you because you say so. At least here is one example mentioned, MAC framework, well if you aware of potential issues you can code own workarounds, use alternatives or approach this in another manner than when you are not aware of such problems. Then there is again the question on how hard it would be for an attacker to exploit and abuse given example to be successful. The argument also goes for Windows, Windows is also vulnerable to architectural issues and design flaws that constantly getting abused such as ABEs.

The hardening required for a reasonably secure Linux distribution is far greater than people assume. You would need to completely redesign how the operating system functions and implement full system MAC policies, full verified boot (not just for the kernel but the entire base system), a strong sandboxing architecture, a hardened kernel, widespread use of modern exploit mitigations and plenty more. Even then, your efforts will still be limited by the incompatibility with the rest of the desktop Linux ecosystem and the general disregard that most have for security.

No proof or specific example given. Some attacks require physical attacks others do not, some problems getting patched others do not get patched or it resolves itself once leftovers or old code gets replace, modernized or entirely removed. This process also happens with Windows. Old and outdated stuff gets removed, replaced or archived. I think he talks about a perfect OS without mentioning how that should be approached and what it would take or give some specific examples.

If you lock down everything you take away freedom, if you leave users a choice it is up to him but he might be more exploitable or his system more vulnerable.

Other Security Researchers' Views on Linux/Windows

First of all you are not a security researcher Madaidan, how dare you are to get in line with Bruce Schneier, other people are researchers and real experts, and you are sure as hell none of them because you have no qualification to call yourself an expert, your - research skills - are copy and paste straight out of Wikipedia and some Bruce Schneier Blog entries, stuff that everyone reads, follows and knows about. So it is pretty obvious to us article readers what your main sources for your claims are. If someone actually talks with you it is quickly revealed what troll you are and that there is absolute nothing behind except Google.

Here is my list about what actual experts have to say about Linux, not that it matter because every system evolves and adopt new security mechanism, you also can cherry pick whatever fits your point of view, which makes such opinion based comparison useless.

• What Kaspersky says about Linux, it is more secure
• Windows violates DSGVO
• BSI analyzed Windows 10 Telemetry
• Research Shows Linux is More Secure and Faster Compared to Apple's MacOS and Microsoft's Windows
• Security research suggests Linux has fewer flaws
• Linux platform is more secure than Microsoft Windows & Apple macOS
• Linux Security: A Survey
• Qubes OS: A reasonably secure operating system
• Chinese Government Ditches Windows
• Germany wants to ditch Windows
• Linux is safer than its competitors because developers race to fix security flaws
• Microsoft Software is Malware
• Windows Secure Boot: Insecure by design and mostly likely can't be fixed
• Researcher finds new way to sniff Windows BitLocker encryption keys
• You Can’t Trust BitLocker to Encrypt Your SSD on Windows 10
• Windows 11 vs Ransomware
• Windows 11: Access through the Android back door
• Patch Management is NOT a managed solution - in fact it kinda sucks
• AskWoody - Entire community dedicated to Microsoft patch madness
• Linux tends to be used by more technically literate people
• Microsoft has its own Linux Distro, it is called CBL-Mariner. Preciously Microsoft had other Linux Distros e.g. SONIC and Azure Sphere OS which was designed for IoT.

Conclusion

• Every kid calls himself a Researcher these days because he opens Google. Researcher is a title you need to earn in the security scene. Browsing the web is not researching it is googleing but an actual researcher also audits systems, stuff Madaidan not once did in his article, the one single example he provides about passwords does not work on what he might call mainstream Distros such as Manjaro. His example aged heavily and most security oriented systems cover it, maybe not fully but reasonable enough to avoid that this quickly gets out of hand, he also entirely fails to provide workarounds or mention anything on how quickly password related things can be secured with some easy methods. He also fails to show that Windows credential storage also can be bypassed or compromised, the guardian mechanism is - by default - also bypassable, as of today. The claims Linux is insecure based upon some examples without mentioning how easy or hard it would be to fix is not professionalism and he put zero effort into it to elaborate this in detail, instead he on another page provides a Linux hardening guide which is widely put as useful as an second asshole because there are already hardened kernels, hardened Distros or you just read a more up-2-date man page because you anyway end up testing it otherwise breakages will occur pretty quickly after a reboot.
• Most of the mentioned arguments aged heavily and lots of stuff is covered in Linux, I am not going to imply Linux is perfect or by default usually configured to be secure but the user has freedom to preinstall already hardened kernels, hardened systems or adjust and adopt himself to various addition layers that he can configure, install and use. This also goes to Windows but Microsoft has here more limitations, which require a specific Windows version, some security features need to fight the hardware requirements and so on, not everyone however has a new CPU with the latest features in it, so older CPU architectures cannot quickly covered like he proposes because there is no official support anymore from Microsoft and in this case it can make sense to switch to Linux that still covers that particular part because why should the user buy a new CPU if the old one still does the job regardless if there are flaws discovered. And then there is also the scenario that older systems or hardware are potentially less of an attack vector because new malware typically focus on - what the mainstream - user uses or what has more potential to get exploited, which means some malware might not be able to run on it due to the fact that the attacker never covered old systems or hardware. Such scenarios are not even mentioned.
• Platform and architecture based security features are not the overall factor that leads to insecurities, the author clearly ignored this part and never covered it. Your ABE protection and all other things are pointless if your platform is already compromised, you are infected by hidden malware and how would some beginner find out about it. Knowledge is one of the key factors that leads to more security.
• He has absolute no evidence for any of his claims that Windows is automatically more secure just because Microsoft added some new features, new features in fact often got exploited, bypassed, slowed-down the OS, we had the whole Core Isolation problematic.
• The presented points why Windows is automatically better lack some expertise because in the real-world there are other factors to consider, the human user, what he installs, privileges, update sources, how he obtains packages, chain of trust. None of those points are covered.
• Many scenarios require root on Linux end, which he does not care to mention.
• There is no final verdict possible, Microsoft gets patched frequently same as Linux, it is your decision what you prefer, install or put on hold. You can defer Windows Update same like you can decide to not use a rolling release Distro. Nothing implies here that just because there is a patch available the average user directly is aware of it and installs it, which can become a problem but it also depends if the attacker exploits actively something that is patched.
• Some prevented features are only available in Windows Enterprise or Pro versions, he simply ignores such argument. Only some newer Windows Builds and Kernels added specific features and flags, so some of the mentioned things once again depend on what the user gets, have preinstalled or prefers to use.
• He does not mention in detail why a user should trust Microsoft, given the history. On his other article how to harden Linux he even claims Telemetry is no problem, actually it is and hardcoded into -dll files such as dnsapi.dll that have the potential to bypass filters and Windows own dns resolution system. None of this is covered, explained or displayed why this makes Windows overall more secure.
• Does not understand difference between OPSEC and isolation based sandbox approaches.
• You can install Defender on Linux too. Not covered at all. This could offer an additional layer of defense, I am not going to say you shall install it but some arguments can countered when the user gets a choice, warning or log system that makes him aware of things. It can potential make things easier, however As, as mentioned are controversial but the underlying point here is that such systems exists and they tend to be reliable if configured, audited and monitored probably. Working with multiple layers can make a difference if you think that you are a target, because when one system fails another can potential cover it, if an AV fails to detect malware the operating system mechanism can kick in and lower damage or even prevent to malware to be successful, we here assume that your system was previously not already infected.

About Madaidan

• Other people even debunked his article e.g. the FlatPak section on multiple occasions as nonsense. He tries to sound smart while he mostly copies stuff, he apparently has no less experience with malware in general or understand the inner to comprehend how it actually influence the operating systems security ring. Most mentioned protection mechanism are useless when already compromised or not even prevent an infection in the first place. They lower possible repercussion that malware could obtain and some of the mentioned security features are highly controversial, to name some BitLocker, SecureBoot, TPM and Co. On paper they are all good but in the real world they can create problems or the user needs to fully trust Microsoft.
• He does not cover the fundamentals such as SELinux and other things that could be used as pro argument for Linux and then explain what exactly Windows does better.
• He clearly does not know what a security researcher does or needs, a security researcher does not copy Wikipedia knowledge from others and resents it as his own. WHich is the full extend of his article.
• He is not an expert nor should someone call him researcher, his research is mainly Wikipedia as main source. Everyone can do this.
• Madaidan plagiarize others.
• No validated research data are proven in any of his backlinks.
• He cherry picks things he believes makes Windows more secure, never mention any downsides such as usability, attack vectors that can occur and automatically assumes that new tech equals more security, I debunked it provided reference that some of those things are weak, exploited or have additional problems. His Linux hardening guidance is pretty much pointless as he states himself that the user shall review everything himself because if you apply everything that he randomly links in an attempt to pretend this is a smart clue pretty much renders your whole OS unusable, this raises the question why did he not just link to the official documentation and call it a day if the user anyway ends up in doing so. This is not professionalism. This is just blindly copying something out of the official documentation or other sources and then randomly list it, this is not hardening at all it is displaying already covered stuff without giving beginners or even advance users a chance to successfully apply it without repercussions, besides it is a waste of time going trough this and then find out that you better have invested the time reviewing official material.
• He probably sees him in line with Bruce Schneier and other actual experts who wrote Tier 1 Level Books, have actual real-world expertise or consult big boys like the NSA, this is not the case, he is someone which you cannot take serious and this is proven with my article. He fails to see any connection between interaction from the usability aspect to the OS provided security mechanism.
• He gives pretty much no expertise, or insights on how hackers directly abuse everything if you trust proven to be secure systems that are proven to be secure and maintained. Windows - after years - tries to provide WinGet and Microsoft Store as secure alternatives, but if you actually check the store and the WinGet abilities, they are far from to be even remotely close to what some Linux systems offer in this regard. Such factors are absolutely not covered and the user most likely, especially on Windows ends up installing cracked and malicious applications much more than the average user who gets his packages from AUR and Co. He also not covers the part that some Windows versions offering less what people might compensate by installing insecure applications in an attempt to harden or add additional features, this is a real threat and drive-by malware like this is more spread on the Windows eco-system. In this regard he also fails to show or elaborate that some security features that Windows directly provides depends on installed Build, Hardware and Software support and that older systems with older hardware components are entirely locked out or not covered in his hypothetical what-if scenario that he sells like everyone would be daily under attack which is not the case and most things could be improved suggesting a multiple layered approach combined with - what he calls standard - hardening techniques. If the attacker then needs to break trough multiple security counter measurements the effort increases and he might give up or it is not worth to target such users in the first place because at the end of the day it is easier to target people who disable all security mechanism because they refer performance or are annoying from Windows popups and banners from Windows Update and Defender.
• Do not call yourself a researcher if you do not know what qualification are required to gain such title. Searching with a search engine is no research and not your own knowledge.

Final verdict - Not so fast friends

There is none, I stated that directly in my opener to not waste your time. We cannot compare entirely different operating systems and architectures and security approaches in a way that cherry picks the good or bad things only and then let important variables out of the equation. For example there is the human aspect and the factor that Windows still is preinstalled on most devices. You cannot per-see claim x is more secure than z, list some mitigation techniques and claim just because Linux has more or less of them compared to Windows results in more or less overall security.

If we want talk statistics then most of mentioned so called attack scenarios are pure hypothetical and Madaidan does not list real-world exploit examples instead he lists CVEs, not even mentioning that there are different levels and just because there are potential weaknesses does not automatically imply insecurities because for an attack to be successful you need to put other things in consideration.

Windows evolves - Linux evolves and the community provides feedback, patches and ideas on both sides to improve it. You can observe, report and present your finding but that that not come to an verdict that withstands a critical look at it, Windows XP was an insecure mess, the times are over and Microsoft learned from such experience and feedback, exactly the same goes for Linux, mistakes have been made and you evolve to acknowledge it and move on.

As a matter of fact Linux is therefore not perfect but claiming Windows is entirely better is just not what the reality tells us, what is problematic are default settings that Windows and Linux delivers, usually not strong chosen and a middle way to avoid usability breakages, these setting can be changed and already then covering a log. Not all but it is often sufficient enough to make it hard for potential attackers to exploit the system, even tho nothing in the universe is absolute and perfect you can make it hard enough so that attackers need to give up and target others that are more vulnerable, this is universal and applies to practical every OS.