Re: [Rpm-maint] [rpm-software-management/rpm] Make 'rpm -V' more resistent against rpmdb manipulations (#196)
Just FWIW, #811 is also a step into this direction. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/196#issuecomment-580175256___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make 'rpm -V' more resistent against rpmdb manipulations (#196)
There is not much one can do on a compromised system as even the tools themselves may be compromised. But there is support for Integrity Measurement Architecture (IMA) and the Linux Extended Verification Module (EVM) in rpm since 4.13 which puts signatures to the security.ima extended file attribute of all (non config) files. Together with storing the keys in the TPM and checking the kernel signature at boot time this much better than anything RPM can hope to achieve with software only. Closing. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/196#issuecomment-580170332___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make 'rpm -V' more resistent against rpmdb manipulations (#196)
Closed #196. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/196#event-2992624343___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make 'rpm -V' more resistent against rpmdb manipulations (#196)
> Hmmm ... its not clear what exploit is used (from just reading the file at > the URL you gave). I think "DIZZYTACHOMETER" doesn't exploit anything itself, but is just hiding e.g. a rootkit installation by manipulating the rpmdb based on already existing write permissions gained before. I didn't find the binary nor any source for "DIZZYTACHOMETER", but the way of usage makes me assuming "regular" rpmdb manipulations, not a RPM related security flaw. > The provision in RPM for careful rootkit forensics is to use "rpm -Vp ..." > from a CDROM (or other offline/immutable media). Immutable media…something that is harder and harder to get when looking to Fedora or RHEL (last with CDN). Sometimes (e.g. at EPEL as 3rd party repository) the RPM package has been already orphaned and thus removed from the repository when it comes to a verification case. > This isn't an easy problem to solve. Right, and I don't expect a quick solution. Just wild ideas: Blockchains for rpmdb? Optionally trusted (digital) timestamping for rpmdb? But yes, maybe also a further verification tool that somehow handles the situation that offline media is going away. I do not have a specific idea how this could be solved, finally. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/196#issuecomment-292949590___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make 'rpm -V' more resistent against rpmdb manipulations (#196)
Hmmm ... its not clear what exploit is used (from just reading the file at the URL you gave). The RPM versions (4.1/4.2) mentioned in the URL are quite ancient (circa RHL 8/9). Even on those ancient systems, /var/lib/rpm requires access to root:root (or rpm:rpm) in order to modify an rpmdb (but the derivative task of the exploit is hiding a rootkit, where root:root has already been achieved, by changing information in the rpmdb). The provision in RPM for careful rootkit forensics is to use "rpm -Vp ..." from a CDROM (or other offline/immutable media). Hardening the manifest of installed packages (i.e. what is in an rpmdb) on an already exploited system would require a security protocol to authenticate/authorize rpm installations, most likely using a TPM and a trusted boot to ensure that the RPM executable was not compromised, and then to keep track of the list of package headers which SHOULD be installed, as well as verifying header signatures before verifying package contents. This isn't an easy problem to solve. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/196#issuecomment-292833133___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
