First of all let me link you to Madaidan's famous Linux Security criticism piece: Linux | Madaidan's Insecurities .
First, I disagree with the introduction to Sandboxing section. SELlinux is built on the containment idea, almost the same idea as Sandboxing. And it has staff_u for admins and user_u for ordinary users. And it partitions those 2 pretty well. The user_u can never sudo to gain root, stops arbitrarily marked SUID programs and cannot administer the system.
The arguments for flatpak and firejail I agree with. In Madaidan's flatpak section, it says sandboxing features are arbitrarily enforced by developers, and that is true. Some are more lax than others. And there should be a fixed implementation. In the firejail section, it notes that firejail is a SUID root program and any vulnerabilities would give the attacker root. And it apparently has happened before.
Madaidan chose 2 good examples but neglected to look at SELinux.
No comment on the 2nd Exploit Mitigation section. As I am no expert in exploits.
No comment on 3rd section on Kernel as I am no expert on kernels.
Section 4 deals with privilege escalation to Root. An account that has access to sudo is as good as gaining root because sudo passwords can be obtained easily via keylogging. Well, thats why there are standard accounts. Standard accounts has no access to sudo. And SELinux makes double sure of that. (note: Red Hat and variants like Fedora, CentOS and Rocky has SELinux) And to overcome keylogging, you get a $27 Yubikey which is a hardware 2FA token; you touch it in addition to providing the password to grant access . Or you have a fingerprint reader on your laptop. Keylogging is also made very difficult now with the now popular Wayland XWindows replacement of X11 XWindows. One window can no longer touch or listen to another.
Section 5 explains more on keylogging.
Section 6 talks about distro specific issues. In particular the article criticizes the 'stable' release model where CVE patches are not backpoprted consistently. And that some developers don't bother to file CVE's so Ubuntu etc don't know which package to backport. It gives Ubuntu and Debian as examples. And it admits that 'rolling' release models now counter that. There are distro's which are 'aggressive' in their releases, like Fedora (updates arrive almost every day) Rollng release big distro's include Arch, openSuse, Gentoo, maybe more.
Section 7 dismisses hardening as a solution and dismisses SELinux as an incomplete MAC solution because majority of apps runs as unconfined_u. And the article mistakenly assumes that we users want to maintain compatibility with the entire Linux ecosystem. Firstly, unconfined_u is just the label give to 'the rest of the system'. All important components already have strict MAC rules written for them. You only have to only list all the rules to see this. SELinux is mature. While hardening may not directly address kernel issues. A good part of hardening is reduction of attack surface. And the less you have running, the less exploitation can find a vector to succeed. Hardening may also involve direct mitigation of known weaknesses. For example, one masks the cups service until it is needed. Hardening may also mean introduction of an network IPS like Suricata that stops a whole slop of attacks.
The article tries too hard to counter the versatility of Linux to make it's point. People DO choose distro's that have strong security. And people DO perform hardening, it is part of a solution. There are always compensating security controls. Faulting Linux is too broad of a stroke.
First, I disagree with the introduction to Sandboxing section. SELlinux is built on the containment idea, almost the same idea as Sandboxing. And it has staff_u for admins and user_u for ordinary users. And it partitions those 2 pretty well. The user_u can never sudo to gain root, stops arbitrarily marked SUID programs and cannot administer the system.
The arguments for flatpak and firejail I agree with. In Madaidan's flatpak section, it says sandboxing features are arbitrarily enforced by developers, and that is true. Some are more lax than others. And there should be a fixed implementation. In the firejail section, it notes that firejail is a SUID root program and any vulnerabilities would give the attacker root. And it apparently has happened before.
Madaidan chose 2 good examples but neglected to look at SELinux.
No comment on the 2nd Exploit Mitigation section. As I am no expert in exploits.
No comment on 3rd section on Kernel as I am no expert on kernels.
Section 4 deals with privilege escalation to Root. An account that has access to sudo is as good as gaining root because sudo passwords can be obtained easily via keylogging. Well, thats why there are standard accounts. Standard accounts has no access to sudo. And SELinux makes double sure of that. (note: Red Hat and variants like Fedora, CentOS and Rocky has SELinux) And to overcome keylogging, you get a $27 Yubikey which is a hardware 2FA token; you touch it in addition to providing the password to grant access . Or you have a fingerprint reader on your laptop. Keylogging is also made very difficult now with the now popular Wayland XWindows replacement of X11 XWindows. One window can no longer touch or listen to another.
Section 5 explains more on keylogging.
Section 6 talks about distro specific issues. In particular the article criticizes the 'stable' release model where CVE patches are not backpoprted consistently. And that some developers don't bother to file CVE's so Ubuntu etc don't know which package to backport. It gives Ubuntu and Debian as examples. And it admits that 'rolling' release models now counter that. There are distro's which are 'aggressive' in their releases, like Fedora (updates arrive almost every day) Rollng release big distro's include Arch, openSuse, Gentoo, maybe more.
Section 7 dismisses hardening as a solution and dismisses SELinux as an incomplete MAC solution because majority of apps runs as unconfined_u. And the article mistakenly assumes that we users want to maintain compatibility with the entire Linux ecosystem. Firstly, unconfined_u is just the label give to 'the rest of the system'. All important components already have strict MAC rules written for them. You only have to only list all the rules to see this. SELinux is mature. While hardening may not directly address kernel issues. A good part of hardening is reduction of attack surface. And the less you have running, the less exploitation can find a vector to succeed. Hardening may also involve direct mitigation of known weaknesses. For example, one masks the cups service until it is needed. Hardening may also mean introduction of an network IPS like Suricata that stops a whole slop of attacks.
The article tries too hard to counter the versatility of Linux to make it's point. People DO choose distro's that have strong security. And people DO perform hardening, it is part of a solution. There are always compensating security controls. Faulting Linux is too broad of a stroke.
Last edited:
