Linux is not really comparable like this because the distribution matters along with the bootloader configuration.

If you have an immutable distro with SELinux configured and your own UEFI keys or a shim with secure boot, you'll have a very different set of vulnerabilities from someone running Mint with secure boot turned off.

For a short time Microsoft marketed an upgrade path the a full Unix like operating system for Windows. It was widely known that some of the Windows shell differences from Unix were just arbitrary aliases for the Unix commands.

If you ever get the chance, try using an old Android device you do not use, enable the developer options for the ADB bridge and try hacking around, if you have an interest in understanding how Linux security works in practice when it is done right. The Linux side of Android is an interesting case study if you understand the premises of Android. It is a Linux system that is secure for people with absolutely no understanding of Linux or networking. This is enabled by allowing the app developer to become something like a full Linux user on the Android device. All of the Linux kernel binaries that could modify the kernel in any way are removed and there is no administrative account present. When the hardware manufacturer logs out for the last time, all the administrative and modifying binaries are deleted. This secures the remaining files that are all marked as read only. Android also has a very robust SELinux implementation in place. Every location present has a defined security context. So there are places where you can create temp files and store data, but the things that can be added and manipulated are very limited in their access to other parts of the system. If you mess around with this the way these tools work will become much more tangible.

By comparison, most distros ship with a very open and unconfigured security context. The SELinux configuration is still extremely permissive in distros with SELinix integrated, like Fedora. This is nothing like Android's setup. The primary reason for a lot of the ROM community on Android and how they have root access is because of exploiting CVE vulnerabilities in the kernel that were found after the kernel was shipped. Android works with orphan kernels that only the manufacturer can update because they retain the source code for the kernel modules that they add at the last minute. This is the depreciation mechanism used by the hardware manufacturer to steal ownership with Android devices.

If you understand how exploiting CVE's works on a simple abstract level, and why it is necessary in order to bypass the immutable system (read only file system without tools to modify Linux kernel binaries), and how SELinux adds further restrictions based on the context of who is accessing the directory or command/executable, you should better understand the complexity of the question you're asking. The app developer on Android is like your equal on the device. They can do what you can do, and that is why you are so restricted too. Your measures of control on Android are very limited and just in the app environment spaces.

Once I learned the basics of this system, it has become the way I view all software systems intended to enable ignorant consumers. Tremendous power to alter systems is included in these platforms, platforms like Windows.

Those that are trying to make the Windows games work on Linux are likely completely focused on functionality. When people talk about things like sandboxing, they are almost always talking about library dependencies and not any kind of security context. It is likely that any malware that targets Windows binaries will not work on Linux directly, but something that targets Linux specifically is another matter entirely; it is security through obscurity, which means no security at all. Unless you've taken active measures to limit the PID/GID/security context of the process that is running the software, it has all the same permissions of the user that called it. It can delete, view, and write anywhere that you can with the user/group/sc that launched it.