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
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
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?
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
Regards
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
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
Regards
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
