Bug 58910

Summary:	[4.2]: feeding RPM update info to tripwire
Product:	[Retired] Red Hat Linux	Reporter:	Alexandre Oliva <aoliva>
Component:	rpm	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	Keywords:	FutureFeature
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-11-16 20:31:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexandre Oliva 2002-01-27 19:15:09 UTC

I use tripwire, but every time I install updates of packages with a large number
of files, such as glibc or the kernel, it becomes pretty much impossible to
verify that no files have been unintentionally (or maliciously) modified just as
I installed the updates.  And, unfortunately, it's not that unlikely to have an
intruder get in just as you install the package that fixes that very security
problem (assuming you always install fixes as they are published, which I do).

It would be nice to have some integration between RPM and tripwire, such that I
could run soem RPM command that would run `tripwire -m c -I' with an editor that
will look at log of modified files, compare their md5sums and timestamps with
those in the RPM database and approve the changes, leaving any other modified
files alone.  It would be nice if it would display the list of
installed/uninstalled packages before committing the changes.  Extra points if
this could somehow be integrated into RHN, so that one didn't have to go into
every single machine of a workgroup after requesting a global update.

Comment 1 Jeff Johnson 2002-01-27 19:28:35 UTC

If the RFE gets into rpm, then python bindings are the only impediment
to using in up2date. Whether RHN chooses to do that is a different
matter ...

Thanks for entering the bug report.

Comment 2 Jeff Johnson 2002-03-18 17:03:02 UTC

Re-implementing tripwire within rpm looks very doable,
will probably take a shot at an implementation this summer ...

Comment 3 Jeff Johnson 2002-07-24 19:13:48 UTC

FYI: rpm-4.1-0.53 and later now verifies
header/digests/signatures whenever a header
is read. AFAICT There are 3 things that remain to
duplicate tripwire functionality on top of
an rpm database:
	a) (easy) sign all the database files in order
	to detect any modification.
	b) (moderate) steal a tripwire configuration
	paradigm, remapping duplicated functionality
	onto existing verify CLI bits.
	c) (moderate) walk the file tree to find files
	not under package management, and %ghost those
	files into a separate, virtual package header.

Comment 4 Jeff Johnson 2002-07-25 12:31:29 UTC

This ain't gonna happen for rpm-4.1, will be addressed in rpm-4.2

Comment 5 Jeff Johnson 2002-11-16 20:32:51 UTC


*** This bug has been marked as a duplicate of 76877 ***