The bad thing is there&#x27;s hardly a generic &quot;more secure&quot; switch.<p>&gt; applying the grsecurity patchset will make your box more secure.<p>It also might not. Correct me if I&#x27;m wrong, but while grsecurity does a good job in kernel hardening, it won&#x27;t protect from attacks like recent imagemagick system() injections, or from something like wordpress exploits, where you don&#x27;t necessary touch kernel space or even binaries at all -- so it might be possible to have grsec enabled system and still be part of a botnet, or leak user data.<p>&gt; enabling SELinux for packaged software.<p>This is a double edged sword also. Good thing is that a lot of software does have SELinux policies for it. Bad thing is that a lot of software runs in <i>unconfined</i> domain and that can give a false sense of security. For instance, if I recall correctly, systemd runs unconfined, while being itself a a) rapidly changing and b) half a million plus LOC software. And to err is human, you know -- SELinux won&#x27;t &quot;contain the bomb as it goes off&quot; in unconfined domain.<p>Another example of bad approach with SELinux would be grepping for something in the audit.log and making policy module, which is even recommended in the official docs [1]. I do understand that its a major PITA to find good balance between convenience and security, but this particular example trains users bad practice from the start. Its worse than dismissing UACs -- its as bad as grepping for dropped packets in firewall logs and autocreating permissive firewall rules. Attacker calls her rootkit &quot;yoursoftware.sh&quot;, tries needed functionality so that denials appear in audit.log, waits until sysadmin greps for &quot;yoursoftware&quot; and voila -- SELinux is perfectly ok and silent with rootkit. Its simplified, but you get the idea.<p>&gt; Hardened Linux From Scratch. Educational, but not practical.<p>If we disable unconfined domain -- and hence be forced to formalize literally every syscall in our access matrix -- then any MAC system also can be called unpractical.<p>I think every statement of a &quot;Use X its more secure&quot; kind is very dangerous, unless you explicitly specify against <i>what kind of threats</i> its more secure. Otherwise, statement just adds false sense of security, and then human laziness kicks in, and we end up with a mess. Like, if I harden the system kernel, but fail to protect the user data -- or vice versa -- I simply end up without any sensible result, while thinking otherwise. Or I can start with perfectly reasonable defaults (same examples like OpenBSD or SELinux) and with few &quot;convenient&quot; commands open up huge security holes, and again, end up with not what I expect.<p>[1] <a href="https:&#x2F;&#x2F;access.redhat.com&#x2F;documentation&#x2F;en-US&#x2F;Red_Hat_Enterprise_Linux&#x2F;6&#x2F;html&#x2F;Security-Enhanced_Linux&#x2F;sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html" rel="nofollow">https:&#x2F;&#x2F;access.redhat.com&#x2F;documentation&#x2F;en-US&#x2F;Red_Hat_Enterp...</a>