Yes, I'm after making sure the system is in "known-clean" state, after a bad-admin/intruder has "potentially" deliberately inserted malicious code somewhere on the server
1) look into "FIPS mode"
Please forgive my ignorance, but AFAICT FIPS mode is a standard specifying a number of known-good algorithms, with apps specifically compiled using FIPS mode compile options, only use FIPS libs and algorithms. This requires application level compile-time support. I'm not quite sure how that applies to the use case in this thread
2) rpm --query --all --verify
Malicious code implanted, is (surely?) not installed by rpms. I don't believe this can really help. Moreover, the rpmDB might have been tampered with. I am willing to trust my CPU/Bios, because, well trust has to start somewhere, and the skills to develop and inject custom firmware, are fairly uncommon (unless some kinda goverenment is after you). However, to trust a simple file like the rpmDB, would be naive eh?
3) System fingerprinting tools such as AIDE
A bit useful, but with system updates being applied all the time, it is really hard to practically benefit from HIDS unless you have a known good snapshot exactly before the intruder got access to the system and with no system updates applied till the time you want to verify :-/ Hardly satisfactory
I can imagine a solution that goes something like:
1- The system is powered off, booted from a known-good live/rescue CD (freshly downloaded, checksum+signature verified)
2- The live OS downloads rpm metadata that are signed by fedora (is this already the yum metadata?)
3- Once downloaded and verified, the live OS starts scanning on-disk files verifying the integrity of all the system, most notably the "basic" security related code (kernel, selinux libs, auditing, rpm-signatures-DB ...)
4- Once verified, the system boots from hard-disk, the now verified basic security code (kernel, selinux ...) get some flag such that no process is allowed to execute unless it passes signature checks from the now known-good rpmDB.
5- All foreign binaries fail to launch, and a log message is logged somewhere till the admin manually approves the 3rd party application (by perhaps assigning it some selinux label?)
6- 3rd party bash/python... etc scripts, should "somehow" be stopped from execution as well, till manually audited and approved
Comments and thoughts are appreciated