tripwire --update --accept-all fails with file not found

[tripwire]

tripwire --update --accept-all fails with file not found

[brc0x1]

Hi Horace, what you have bumped into here is a longstanding annoyance with OST's command line & variable handling: The $(DATE) variable always resolves to the current time, so if you use it in REPORTFILE it'll generally resolve to a filename that doesn't exist. This behavior is great for checks, since it ensures you get a new, uniquely named, report file for each check. But the flip side of this is that anything that needs to refer to an existing report file (like printing a report, or updating your db) will error out looking for a nonexistent report file named with the current date & time.

I see that you've already discovered the two ways of preventing this: Either modify REPORTFILE to not use the DATE variable (in which case a new report would overwrite an existing report file with the same static name), or always specify --twrfile when running an update. One way to make the 2nd approach less annoying would be to write a small shell script that identifies the newest .twr file in the report directory and passes that filename to tripwire or twprint as the parameter to the --twrfile argument. Here are a couple of Stackoverflow threads debating the best way to solve the "find the newest matching file" problem in a Bash script, with multiple examples, so that might be a good place to start. https://stackoverflow.com/questions/5885934/bash-function-to-find-newest-file-matching-pattern and https://stackoverflow.com/questions/1015678/get-most-recent-file-in-a-directory-on-linux/23034261

[brc0x1]

Correct. Running in --check mode is what does the compare & contrast against the database. As it does this, it leaves the database alone, unmodified, and writes any changes it sees to a report file. So if file X changes, and you have a daily cron job that checks this file, tripwire will continue reporting it as changed until it's changed back to its expected state, or the database is updated with the new expected state.

So --update mode handles this by taking the observed state from some previous check (i.e. a report file) and merging it into the database. The "--accept-all" argument tells update to go ahead and merge all changes in a report into the database; without that argument, we launch an editor containing a report, and from there you can select individual files/directories to be updated.

If you want to do this immediately after a check, the "--interactive" argument to check mode is a shortcut way to run a check and then selectively update the database all in one operation.

If file X changes regularly, and you've concluded it's just noise and you don't want to see it anymore, a third option is policy update mode. In this mode, you pass it an updated policy text file, and it runs a check on the union of the old & new policy files, and then updates the database, adding newly monitored objects, removing things that are no longer monitored, and updating objects where the monitoring has changed (like if you start monitoring additional attributes on a file you were already watching).

If you run a policy update with "--secure-mode high", it errors out if it sees other changes that aren't related to the updated policy, to prevent unwanted changes from sneaking into your database during the policy update.

[bugz8unny69]

I worked around/fix this by pointing --twrfile to a report file after tripwire --check invocation.

[bugz8unny69]

I have cron job that sends me reports either by hour or daily via E-Mail, aside from updating the system, the changes are minimal and innocuous. Point is, I don't have to run update often. I wonder why the report is necessary doh? And does have to be the latest?

[brc0x1]

Ok, the report file contains all the change data observed during a check, so a db update is the operation of importing element states from a report file into a TW database file, replacing previous element states as needed. Report files are meant to be a self-contained format so (for example) you can copy a report file to another machine and print it there without requiring the database, policy, config file, or keys from the originating machine.

You're correct that you don't need to use the latest report file in an update; the only limitation here is that the db and report can't be out of sync. Suppose you have a folder with the last 20 reports generated, all of which were created after the last db update. You can update your db with any of them. Once you've done that, though, the db has been changed and you can't update your db with the same report file again, or with any of the other reports generated before the db update. Now let's say that your next hourly check runs, and it detects a few changes and writes out a new report file. This new report file can be used in db updates, since it's in sync with the current db state and the older files no longer are.

[bugz8unny69]

Oh, so on Tripwire update, it doesn't do a compare and contrast against the database, insteads import the changes from the report file? Am I understanding this correctly?

[bugz8unny69]

Thanks for answering all my questions.

Cordially yours.

P.S. If I have any more questions, I will re-open this issue.