On Wed, Aug 12, 2009 at 3:09 PM, <Greg_Swift@xxxxxxxxxxxxxxxxx> wrote:
Well, depending on any changes you've made and how big the install base is,
> 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.
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)
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.
anyone else?
-greg
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
