Guaranteeing running code is signed

Björn Persson bjorn at xn--rombobjrn-67a.se
Sun May 10 13:03:24 UTC 2009


Ahmed Kamal wrote:
> while rpm's verify options are useful in many cases, they are not in this
> one. The use case is, Admin A takes ownership of server-C from admin B,
> admin-B might have infested server-C with all kinds of "custom" code (and
> even worse, scripts executing as root). How does admin-A ensure no custom
> code (scripts are probably even harder?) is running on server-C.This looks
> to me like it needs collaboration from the auditing subsystem (whenever a
> process starts), and selinux (detecting/blocking) executables not meeting
> signing requests, or at least logging what happened

If your concern is that admin B may have been incompetent and messed up the 
system with crappy code and bad configuration so that it doesn't work 
properly, then you could verify the whole system against the RPM database and 
review everything that has changed and anything that isn't in the RPM 
database.

If your concern is that admin B may have been malicious and deliberately 
implanted malware in the system, or that intruder D may have broken into the 
system and implanted malware because admin B didn't keep the system secure, 
then you have to wipe the disk and reinstall from known good installation 
media, and then restore as little as possible from backups and scrutinize 
anything you do restore.

It's impossible to verify the security of a computer system from within the 
system itself. If a malicious person may have had root access, then RPM, GPG, 
SElinux and the auditing subsystem may all have been tampered with and you 
can't trust that they tell you the truth. Reinstalling is the only way to be 
sure.

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090510/a60e7a31/attachment.sig>


More information about the fedora-devel-list mailing list