> > > I tried your suggestion and it works, however, since it implies > > reinstalling all the packages from their RPM files, though in > > database only, is no so different from reinstalling them completely. > > If no standard solution is available, I was looking for a sort of > > hack such as a query to manipulate the database directly. I guess > > RPM development team should take this in consideration because it > > allows a better portability of every RPM-based installation. > Well, depending on any changes you've made and how big the install base is, > it can be a lot smaller and quicker to perform. I think some would argue > that having an easy direct way of manipulating the database would defeat > some of the purpose of the security the RPM database helps provide. > In ALL the security text i have read - FWIW i am also a CEH - the > integrity check offered by the command rpm -V it is considered > having little, if any, importance from a "security" point of view.. > And not because it is or not so easy change an rpmdb but rather > because the database - the rpmdb - from which the verification is > done is put on the same local machine. It would be equivalent to > have the aide db on the same machine on which aide do the check: > just for the paranoid the same aide may have been changed for > hiding track o change. Hence the birth of products which carry out > such checks in a centralized manner, by placing also little > confidence using program staticaly linked for doing the security > integrity check (for example http://rfc.sf.net) very good point. > > > > Take for instance this scenario: > > > > A hacker gets on my box and does a relocate of an important package (like > > procps) to a directory outside of everyone's path, and then drop installs a > > custom rpm with a name like procps- that provides similar files, but with > > malicious content. A rpm -qaV show the files all validating fine, and a > > rpm -q --whatprovides shows something that looks right... it isn't a pretty > > thought. > > > Although... i'm not sure if procps is relocatable. But i think the point > > still stands. > > I can always do a --badreloc anyway. I just read the man page for badreloc, but i'm still not sure I get what it is for... could you expand on that? -greg _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
