This is heavily dependent on hardware platform (namely, UEFI - and therefore SecureBoot, which is very foolishly being advocated given its limitations - are x86-only). While this might be acceptable for most users, this ignores that non-x86 workstations do still exist.
> Has a robust MAC/RBAC implementation (SELinux/AppArmor/Grsecurity) (CRITICAL)
This is too specific; there are plenty of operating systems with a much better security track record than even GNU/Linux that don't implement MAC or RBAC (namely, OpenBSD), and it misses the point of MAC/RBAC: privilege separation. Really, the goal here is for any given program to only have the minimum necessary permissions required for it to do its job. You can do this quite effectively by keeping running services/daemons isolated to dedicated users with a minimum permission set (this is, in fact, the core of how Android apps are sandboxed), especially when paired with a proper sandboxing solution.
The nice thing about MAC and RBAC is that they have policy implications; when used properly, they can clearly define the level of access some running program should have to a given part of the system. They also tend to go hand-in-hand with fine-grained control over resource access, but it's not correct to conflate access control mechanisms with granularity (you can have a fine-grained DAC-based system or a coarse-grained MAC-based system).
> Use full disk encryption (LUKS) with a robust passphrase (CRITICAL)
Or (inclusively) a key file (preferably one which is password protected).
> Make sure swap is also encrypted (CRITICAL)
Or just don't use swap. Even with encryption, if data can be ephemeral, it should be.
> Set up a robust root password (can be same as LUKS) (CRITICAL)
I very strongly disagree with this. As much as I dislike Ubuntu, it does one thing right: it defaults to disallowing any sort of direct root login (by setting root's password to some randomly-generated garbage during installation, IIRC), requiring all root access to be done with sudo unless the user explicitly sets a root password.
I especially very strongly disagree with the suggestion that the disk encryption password should be the same as any other password, let alone the root password that shouldn't exist in the first place (well, more precisely, should exist but should be entirely unknown to anyone or anything, including yourself).
> Globally disable firewire and thunderbolt modules (CRITICAL)
This, along with the recommendations to not use hardware with such ports, should be marked as (PARANOID). While it's certainly a good idea if you know they won't be necessary, there are plenty of valid use cases for them (particularly on Apple hardware; while Thunderbolt display support is still sketchy on Linux, it's still a very common use case), and such actions meet (PARANOID)'s criteria much closer than they do (CRITICAL)'s.
And really, while FireWire and Thunderbolt do have specific security implications (due to them effectively being hotpluggable PCI and PCI-E, respectively), this should hold true for any port on one's machine. Any connector can be a security liability when confronted with a sufficiently-motivated attacker.
> Configure the screensaver to auto-lock after a period of inactivity (MODERATE)
This needs to be (HIGH), if not (CRITICAL). Why bother with some FireWire jig like what this guide is so afraid of when the machine's already unlocked?
> Installing rkhunter and an intrusion detection system (IDS) like aide or tripwire will not be that useful unless you actually understand how they work and take the necessary steps to set them up properly
None of the things in this guide will be that useful unless you actually understand how they work and take the necessary steps to set them up properly. None of them. Not MAC. Not RBAC. Not grsecurity and PaX. Not SELinux. Not LUKS. Not passwords. Nothing. This sentence is entirely meaningless.
Not to mention that rkhunter should probably be (MEDIUM)...
> SSH is configured to use PGP Auth key as ssh private key (MODERATE)
What? That's a terrible idea. It's as terrible an idea as using the same password for root and LUKS. If one key is compromised, now the other is, too, because they're the same key.
This is really just a waste of effort and time. The normal approach is to just generate two separate keys, and there's no reason to deviate from this; doing so will just make your life harder and less secure.
> Has a robust MAC/RBAC implementation (SELinux/AppArmor/Grsecurity) (CRITICAL)
This is too specific; there are plenty of operating systems with a much better security track record than even GNU/Linux that don't implement MAC or RBAC (namely, OpenBSD), and it misses the point of MAC/RBAC: privilege separation. Really, the goal here is for any given program to only have the minimum necessary permissions required for it to do its job. You can do this quite effectively by keeping running services/daemons isolated to dedicated users with a minimum permission set (this is, in fact, the core of how Android apps are sandboxed), especially when paired with a proper sandboxing solution.
The nice thing about MAC and RBAC is that they have policy implications; when used properly, they can clearly define the level of access some running program should have to a given part of the system. They also tend to go hand-in-hand with fine-grained control over resource access, but it's not correct to conflate access control mechanisms with granularity (you can have a fine-grained DAC-based system or a coarse-grained MAC-based system).
> Use full disk encryption (LUKS) with a robust passphrase (CRITICAL)
Or (inclusively) a key file (preferably one which is password protected).
> Make sure swap is also encrypted (CRITICAL)
Or just don't use swap. Even with encryption, if data can be ephemeral, it should be.
> Set up a robust root password (can be same as LUKS) (CRITICAL)
I very strongly disagree with this. As much as I dislike Ubuntu, it does one thing right: it defaults to disallowing any sort of direct root login (by setting root's password to some randomly-generated garbage during installation, IIRC), requiring all root access to be done with sudo unless the user explicitly sets a root password.
I especially very strongly disagree with the suggestion that the disk encryption password should be the same as any other password, let alone the root password that shouldn't exist in the first place (well, more precisely, should exist but should be entirely unknown to anyone or anything, including yourself).
> Globally disable firewire and thunderbolt modules (CRITICAL)
This, along with the recommendations to not use hardware with such ports, should be marked as (PARANOID). While it's certainly a good idea if you know they won't be necessary, there are plenty of valid use cases for them (particularly on Apple hardware; while Thunderbolt display support is still sketchy on Linux, it's still a very common use case), and such actions meet (PARANOID)'s criteria much closer than they do (CRITICAL)'s.
And really, while FireWire and Thunderbolt do have specific security implications (due to them effectively being hotpluggable PCI and PCI-E, respectively), this should hold true for any port on one's machine. Any connector can be a security liability when confronted with a sufficiently-motivated attacker.
> Configure the screensaver to auto-lock after a period of inactivity (MODERATE)
This needs to be (HIGH), if not (CRITICAL). Why bother with some FireWire jig like what this guide is so afraid of when the machine's already unlocked?
> Installing rkhunter and an intrusion detection system (IDS) like aide or tripwire will not be that useful unless you actually understand how they work and take the necessary steps to set them up properly
None of the things in this guide will be that useful unless you actually understand how they work and take the necessary steps to set them up properly. None of them. Not MAC. Not RBAC. Not grsecurity and PaX. Not SELinux. Not LUKS. Not passwords. Nothing. This sentence is entirely meaningless.
Not to mention that rkhunter should probably be (MEDIUM)...
> SSH is configured to use PGP Auth key as ssh private key (MODERATE)
What? That's a terrible idea. It's as terrible an idea as using the same password for root and LUKS. If one key is compromised, now the other is, too, because they're the same key.
This is really just a waste of effort and time. The normal approach is to just generate two separate keys, and there's no reason to deviate from this; doing so will just make your life harder and less secure.