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.