For a while the NSA was using OpenStack + CentOS + SELinux in at least some environments. I have no idea if they are still using the hardcore bare-bones SELinu

For a while the NSA was using OpenStack + CentOS + SELinux in at least some environments. I have no idea if they are still using the hardcore bare-bones SELinux that does not have targeted (MLS-only) and unconfined policies. I'd buy them a few rounds of drinks if they are still subjecting themselves to that. I also have no idea if they are still using CentOS after CentOS-8 Stream happened. I believe their focus was compartmentalization, documentation and strict change control. I have no idea what the CIA is using. What I would do is probably something similar to what the NSA is/was doing and include multiple certified 3rd party code reviewers and penetration testers that would not just look for bugs and vulnerabilities but also vulnerable platform concepts, i.e. anything that lends itself to Instrumental Convergence [1]. I would ensure all hardware is using CoreBoot BIOS/firmware and have teams pentest that code. I would hire teams of document writers to ensure everything is documented and has the correct security classification annotations. I would also hire investigation firms to look into everyone that has ever contributed code to OpenStack and RHEL/CentOS. I would require IBM/Redhat to de-obfuscate any obfuscated code and use an NSL to order them to provide technical details on any undocumented weaknesses or intentional lawful intercept code. I would have them also contribute to the upstream kernel more sysctl and /sys tunables that can improve anti-tampering and prevent changing capabilities on the fly. I would also use NSL's to get the firmware of all hardware in the servers. Any applications used by the organization would also have to be retrofitted with instrumentation that can be monitored real time by machine learning to determine if anything suspect is afoot. The monitoring would use short dictionary coded signals vs. verbose English to reduce transmission time, being entirely documented in the man pages. I would ensure that change control while strict would also be semi-agile in that one could make changes quickly if they, their supervisors and their peer reviewers have the appropriate security clearances. Their security clearance would map to one or more security levels and categories in SELinux. If they are DENIED then security guards would rush into the room with cans of silly string, assuming that is still a thing. I would repeat the entire process non stop and ensure any fixes are implemented up-stream so that all businesses may also benefit from improvements and full transparency. There are many more things that would have to be done but I don't think even a summary would fit on HN. [1] - https://en.wikipedia.org/wiki/Instrumental_convergence https://en.wikipedia.org/wiki/Instrumental_convergence