<div dir="ltr">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<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="h5"><br>
</div></div>1) look into "FIPS mode"</blockquote><div><br>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<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) rpm --query --all --verify</blockquote><div><br>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?<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3) System fingerprinting tools such as AIDE<br>
<font color="#888888"></font></blockquote><div> </div></div>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<br>
<br><br>I can imagine a solution that goes something like:<br><br>1- The system is powered off, booted from a known-good live/rescue CD (freshly downloaded, checksum+signature verified)<br>2- The live OS downloads rpm metadata that are signed by fedora (is this already the yum metadata?)<br>
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 ...)<br>
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.<br>
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?)<br>6- 3rd party bash/python... etc scripts, should "somehow" be stopped from execution as well, till manually audited and approved<br>
<br>Comments and thoughts are appreciated<br><br>Regards<br></div>