[JoachimSchipper]

For any Linux distro, applying the grsecurity patchset will make your box more secure.

RHEL (and thus, CentOS) does a pretty good job of configuring and enabling SELinux for packaged software.

There is a Hardened Gentoo. All the fun of normal Gentoo, but with fewer companions to find the compiler bugs. ;-) Still, they've built quite a stack of security patches, including grsecurity.

There is (used to be?) Hardened Linux From Scratch. Educational, but not practical.

OpenWall Linux is dead-ish, but - as you'd expect from a Solar Designer product - introduced several interesting patches (some backported from OpenBSD). You may be interested in http://www.openwall.com/presentations/Owl/.

I recommend - and use - OpenBSD, but there are definitely people interested in security in the Linux world.

[nickpsecurity]

Oh darn, you beat me to OpenWall. It's one of the earliest attempts at securing the Linux mess that many forget about. Solar Designer deserves some credit for his effort. Modern stuff, esp hardened RHEL or Gentoo, is far better option due to maintenance if nothing else.

[dpv]

The bad thing is there's hardly a generic "more secure" switch.

> applying the grsecurity patchset will make your box more secure.

It also might not. Correct me if I'm wrong, but while grsecurity does a good job in kernel hardening, it won't protect from attacks like recent imagemagick system() injections, or from something like wordpress exploits, where you don'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.

> enabling SELinux for packaged software.

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 unconfined 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't "contain the bomb as it goes off" in unconfined domain.

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 "yoursoftware.sh", tries needed functionality so that denials appear in audit.log, waits until sysadmin greps for "yoursoftware" and voila -- SELinux is perfectly ok and silent with rootkit. Its simplified, but you get the idea.

> Hardened Linux From Scratch. Educational, but not practical.

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.

I think every statement of a "Use X its more secure" kind is very dangerous, unless you explicitly specify against what kind of threats 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 "convenient" commands open up huge security holes, and again, end up with not what I expect.

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

[JoachimSchipper]

You're right, but I just wanted to give some pointers, not write a novel on software security (modelling). ;-)

With respect to SELinux: I'm not a fan in all regards, but if you want to use SELinux, the fact that RHEL has pre-made policies for you does help.