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
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
