Kernel: 5.8.0-31-generic x86_64 bits: 64 compiler: gcc v: 10.2.0 Desktop: i3 4.18 Distro: Ubuntu 20.10 (Groovy Gorilla)
tripwire works fine on VM but segfaulted on host see below:
I get the following when I run tripwire --init -v
sudo tripwire --init -v
Open Source Tripwire(R) 2.4.3.7.0 built for x86_64-pc-linux-gnu
Open Source Tripwire 2.4 Portions copyright 2000-2018 Tripwire, Inc. Tripwire is a registered
trademark of Tripwire, Inc. This software comes with ABSOLUTELY NO WARRANTY;
for details use --version. This is free software which may be redistributed
or modified only under certain conditions; see COPYING for details.
All rights reserved.
Opening configuration file: /etc/tripwire/tw.cfg
This file is encrypted.
Opening key file: /etc/tripwire/site.key
Opening key file: /etc/tripwire/zika.gattaca.net-local.key
Please enter your local passphrase:
Opening key file: /etc/tripwire/site.key
Opening policy file: /etc/tripwire/tw.pol
This file is encrypted.
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Processing: /usr/sbin
--- Generating information for: /usr/sbin
Software interrupt forced exit: Segmentation Fault
Segmentation fault (core dumped)
Just in case to prevent you from copy&paste I found myself some answers:
Hi Shane, couple of things you can try right away --
Your log seems to indicate the init stumbles over something in /proc. If you don't need to scan /proc at all, you can just add a "! /proc ;" line to your policy to exclude it.
Alternately you can try an "--init --verbose", which should tell you which file (or /proc pseudo-file, in this case) it's failing on. If you try this a couple of times & it fails consistently on the same object, or same type of object, that would be a clue there's something special about it that we need to deal with. I don't have a 17.04 vm right at hand, but I'll try scanning /proc on 16.04 and see what happens on my end.
One other thing that's been known to cause segfaults is the combination of statically linked binaries and remote directory services (NIS, LDAP, AD, etc.). (See issue #11 for a previous example). If that turns out to be the problem, you can either a.) use the RESOLVE_IDS_TO_NAMES=false config file option (introduced in OST 2.4.3.2), or use dynamically linked binaries instead.
I ran in that problem as well and have a page about it here.
The final solution, in my case, was to edit the
twcfg.txt
file and add theRESOLVE_IDS_TO_NAMES=false
there.However, I first commented out a few files:
/proc
&/dev
and the/boot
which in my case had some remote mounted folder which tripwire says it doesn't like. These are known to cause issues.Two other possibilities: a while back, I had a file which was over 2Gb and apparently tripwire was chocking on those. The
/usr/sbin
folder should not have such, though.One person mentioned that he had a file with -r-------- (400) permissions in his
/usr/sbin
folder. By tweaking his policy file, he hid that file and then it worked. You may be in the same situation. I could not see such a file in my/usr/sbin
folder, though.Finally, Teakwood J Overclutch, who had the same issue, fixed it by recompiling tripwire from the source. If nothing else works for you, this may be the solution. I would imagine that the Debian/Ubuntu builds use the same source, but they may have patches, some of which may break something!