The purpose of this document is to make the system as secure as possible. It's not meant to make deployment or maintenance easier.
Is it problematic to have things you might need somewhere else? Sure. Can keeping those processes running on the system make it less secure? Probably. The entire reason you keep the smallest subset of executables, scripts and processes running is so you avoid any potential holes.
The NSA is choosing security over convenience. For systems that actually contain information that needs to be secure(medical/financial records, governmental data, etc.), I definitely wouldn't choose the convenient choice over the secure one.
And really, this document doesn't go nearly far enough to really harden your average Linux machine... jesus christ they don't even mention what services will run under what roles, reduced capabilities, device ownership... it's a really bare minimum document. But that's not why I critiqued some sections. I critiqued them because some parts are, to me, just stupid.
Like I mentioned twice, there is no potential for a security compromise from simply having excess "files" on a system. You have to actually have a security hole which can be taken advantage of by those files.
What are the files in question? Well, all sorts... icons, manuals, libraries, executables, .... ah, there's where we might see some potential for a security hole (heh, realistically even the icon files could be, but that's out of scope). And how could an executable by itself be a security hole? Usually it's got some modified permissions which allow it to run as another user (commonly root). They should be designed to be secure against an attack but nothing is bug-free. So you know what you do? You remove those permissions. Suddenly it's just a normal executable with the same capabilities as any other executable on the system (of which there are many even on a minimal system).
To accomplish this monstrously difficult task you can simply follow the rest of the NSA guide and it will secure these files for you. Hence, it was (imho) stupid for them to tell you to only install what you need, as their own guide removes any possibility that these excess files could do any damage to the system. On top of that, it's really annoying from the perspective of people who just want to get shit done.
Or you don't even leave it on the system, which means that it can't exploit the hole. If you're aware of the hole, you don't put it on the system in the first place, and if you don't know about it, it's impossible for someone to use an exploit that doesn't exist.
That's rather simpler than leaving it on there, and hoping that permissions work. Nothing's bug free, so why take the chance?
That assumes you have unlimited physical access. 5 minutes per machine * 80 in a rack * 1,000+ racks is a real world limitation.
PS: The NSA has a vary different approach to security than the average firm. To put this in perspective they have been known to refer to their computing power not by computer or rack but by the Acre.
(Also, what's your datacenter or machine profile that you can get 80 machines per rack and not hit overheading or overload your rack power circuits? We could only get 40 to be stable, but we were using commodity gear)
Your attacker could hire a private army and drive tanks into the datacentre and steal your data. But that's unlikely to happen.
Security is about layers, and I think as a security agency, the NSA did a pretty good job. Choose how many layers you want, and which are appropriate.
I'm pretty sure the NSA still has to maintain their vast networks of computers. You don't need to be in a software shop to eventually require a new dependency. Networks of servers are hardly ever static. At some point you will need to deploy/upgrade/patch an application, troubleshoot an error or a network glitch, or support some added functionality. It is far less problematic to have the software available than deal with the potential fallout of problems of maintaining such a network and its access to installing software remotely.
Also, clearly you have never read the source to yum or dealt with its myriad bugs and functional inconsistencies. Let me just tell you that indeed, yum is horrible, and I urge you to avoid it whenever possible.
> It's better to keep /boot separate so that when you upgrade, say, your ext3 root filesystem to ext4, your bootloader will keep on working if the upgrade were to b0rk.
What are you going to do with a system with only a /boot partition? Install busybox? If you want a new filesystem you should be kickstarting via PXE and reinstalling the whole thing, not upgrading in place.
> Say the machine is in a cage in a rack. There is a BIOS password to prevent you changing the boot order and other settings. In this case a password for the boot loader could make sense.
If you've got physical access to the machine in the cage you can do anything you want, which includes bypassing BIOS and Bootloader passwords in about 5 minutes.
> The machine is in a cage in a rack. A locked cage.
You've never noticed that the cages are easy to scale? If i'm going to attack the datacenter i'm going to have a fake badge and pick up the key at the front desk anyway. Trust me, most datacenters are not really that hard to get into. NSA datacenters on the other hand...
> TCP wrappers can give application level warnings that iptables can't.
No, iptables can give you the exact same warning tcpwrappers will, which is access control based on host or IP. There are lots of ways to replicate it with iptables. The more important thing to note is that it's fucking retarded to rely on host or IP level access control of a network service. It's somewhat useful in preventing mass brute-force network attempts, but you should also have iptables rules in place to stop that.
> If possible. You could admin using a kvm if you wanted, but yeah disabling OpenSSH is kinda silly, restricting to a management subnet is better.
A kvm won't transfer files for you and it's usually pretty hard to script 1,000 KVMs to run automated commands in 10 minutes.