Guaranteeing running code is signed

Ahmed Kamal email.ahmedkamal at googlemail.com
Sun May 10 19:30:12 UTC 2009


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

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090510/956ac600/attachment.htm>


More information about the fedora-devel-list mailing list