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.
Willing to relocate: Yes, for the right opportunity.
Technologies: All things Linux (Debian, MTA, DNS(SEC), IPSec, netfilter, routing, dh_make>ansible>puppet) with emphasis on security; Cisco, CheckPoint, BlueCoat; on a dev side: Python, Bash, sed, awk.
Résumé/CV: upon request. For a quick skillset demo, please start with my SELinux playbox here: https://solas.is/secure/ .
Email: if+ycombinator at solas.is
Looking for a security consulting work, but don't mind DevOps, and will surely grab any opportunity to work with exotic security systems (TCSEC B3 and above).
I never bothered to count exact numbers, but from my experience, close to two thirds of all people, when presented with root shell and no consequences, will run rm -rf in some way.
Humble ones issue "rm -rf /usr" or "rm -rf /lib", others go straight to "/bin/rm -rf /". I've seen one person do "rm -rf /* ", immediately followed by "find / -delete". I'd really like to take a peek on his/her thought process at that moment, looked like the desire of destruction was really strong in that one particular brain ;-)
So yeah, while its not particularly useful one, there's indeed a situation where one definitely want to run it.
disclaimer: I run SELinux playbox with free root access and session recording, and peeking into what others do is also fun.
> 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...