Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Reliable way to determine package which own/update a file
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 308

PostPosted: Tue Mar 04, 2014 9:55 pm    Post subject: Reply with quote

cboldt wrote:
My impression was that you had three sets of "suspect" files.

Those that tripwire flagged.
Those that the package manager knows about, but md5sum mismatch.
Those that the package manager doesn't know about.

I was trying to expand the size of (at least) the third list, by finding all of the files that tripwire is checking that aren't known to the package manager; and maybe expand the size of the second list, by checking 100% of the files that the package manager knows about.

I also remarked that the third list might be expanded by using a cruft checker.

The list of files flagged by tripwire is what it is. I think you said you had 17 of them. Rather than check all of the files owned by the packages that threw those 17 errors, you could check just those 17 files, yes? Once those flagged files were found to be (or made to be) acceptable, you could update the tripwire database using `tripwire --update`, which only acts on the files reported by `tripwire --check`.

You also mentioned that your "full file list" has 5815 lines. That's a mighty short "full file list," and one that appears to originate from tripwire. In comparison, here is the way that I used to count the "obj" entries in installed packages:

Code:
> cat /var/db/pkg/*/*/CONTENTS | grep "obj " | wc
194155  776985 20873849


That's some 194 thousand files, and that list is incomplete, compared with all the files that actually exist!

The package/md5sum check is different from the tripwire check, meaning that it is looking at a different group of files or different "full file list." There is probably some overlap; there are files in the tripwire check that are missing from the package/md5sum check; and there are files in the package/md5sum check that are missing from the tripwire check.

I see the tripwire check and the package/md5sum check as independent, correlated only where both checks are looking at the same files. My objective was to make the list of suspect files as big as possible. Most of the suspect files are easily cleared, you will know at least why they have been changed, if not how. There will be a few true mystery files (lots of them around gcc and gcc-config) to provide research entertainment 8O


I had suspect files identified by tripwire (the full file list - just what I extracted from the tripwire report) which I was trying to use the package manager information to verify the majority of them - which resulted in two file lists needing me to investigate further:-
(a) those the package manager knows about but says they don't match expected information e.g. md5sum
(b) those the package manager does not think are owned by packages

Tripwire identifies 5815 items, of which 20 failed package checks (a) above, and 196 are not owned by packages (b) above.
I gave an example of (a) in the original post - vim, an example of (b) was /lib/cpp

Your script helps reduce list (b) by allowing me to eliminate directories and symlinks to package owned files :)

Thanks for your explanation ... it certainly gives me a few things to think about 8)
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 308

PostPosted: Wed Mar 05, 2014 11:20 pm    Post subject: Reply with quote

khayyam wrote:
jonathan183 ... you should try to avoid using 'cat' like this (called UUoC, "useless use of cat"), its an extra call and pipe, and as 'grep' can be provided the filename as input its "useless".
guilty as charged ... and probably a few others on the awards page :wink:

Quote:
note I'm missing the input file in the above ... doh!


sample from file - it's just a redirect of tripwire output

Code:
Parsing policy file: /etc/tripwire/tw.pol
*** Processing Unix File System ***
Performing integrity check...
Wrote report file: /var/lib/tripwire/report/Desktop-PC-20140301-145726.twr


Open Source Tripwire(R) 2.4.2.2 Integrity Check Report

...

-------------------------------------------------------------------------------
Rule Name: Tripwire CFG and Data (/etc/tripwire/tw.cfg)
Severity Level: 100
-------------------------------------------------------------------------------

Modified:
"/etc/tripwire/tw.cfg"

-------------------------------------------------------------------------------
Rule Name: Tripwire CFG and Data (/etc/tripwire/tw.pol)
Severity Level: 100
-------------------------------------------------------------------------------

Modified:
"/etc/tripwire/tw.pol"



Quote:
Something similar came up in another thread where the md5sum was checked from CONTENTS ... maybe of some interest.


I had been copying /etc from one system to another and then modifying, identifying which files I actually modified suggested in the thread you linked to is a better solution thanks.
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 308

PostPosted: Wed Mar 05, 2014 11:32 pm    Post subject: Reply with quote

mv wrote:
You might want to have a look at find_cruft of the mv overlay. It has a default list of exceptions but allows for rather generic configuration files to modify/extend it to your purpose. The problem is that people consider different things as "cruft" (/usr/src or some files under /var are such examples). [advertisement] Also, I think that the configurable handling of symlinks (so that a file in /lib64/Bla.so but recorded in the database as /lib/Bla.so will not considered as craft if /lib is a symlink to /lib64) is a rather unique feature of find_cruft [/advertisement]


interesting ... I'll take a look thanks 8)
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 308

PostPosted: Wed Mar 19, 2014 1:05 am    Post subject: Reply with quote

OK this journey has been good for me 8)

I have come to the conclusion there is no automated tool for determining files etc that belong to a package. The data as far as it goes is contained in the /var/db/pkg tree. That after eliminating files (obj), directories (dir) and symbolic links (sym) there are still quite a few files/directories/symlinks left as suspects.

It is possible to split things into deleted files/directories/symlinks, symbolic links, files in /lib/modules, and character special. This results in a number of suspect files which must be manually investigated and eliminated.

For me the sensible way of dealing with this is storing known good file lists together with md5sum values, symbolic links with targets etc so they can be compared with current lists to allow automated removal of suspect items not verified by the package manager.

Differences between previous and current scans can be used to focus effort on required areas to investigate, and will be needed to avoid multiple investigation of the same files each time a scan is completed.

The package management is kind of missing an http://boingboing.net/2007/08/20/flowchart-is-it-fcke.html category :roll:
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum