Segmentation fault about tripwire-open-source HOT 4 CLOSED

Quick addendum - my 16.04 proc test succeeded, after adding a stop point for the enormous /proc/kcore file since I didn't want to wait forever. You might want to verify that your policy excludes it.

from tripwire-open-source.

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.

from tripwire-open-source.

Hi,
Thanks for the quick response. I cloned the kvm image from prior to my latest apt-get upgrade and ran tripwire across that with no issues. I'm currently cloning the image from post upgrade and will run the verbose against it. At one point I removed /proc and adjusted it to show as below - that also failed. Will keep you advised.
#remove /proc and add the following
/dev/pts -> $(Device) ;
/proc/devices -> $(Device) ;
/proc/net -> $(Device) ;
/proc/tty -> $(Device) ;
/proc/sys -> $(Device) ;
/proc/cpuinfo -> $(Device) ;
/proc/modules -> $(Device) ;
/proc/mounts -> $(Device) ;
/proc/dma -> $(Device) ;
/proc/filesystems -> $(Device) ;
/proc/interrupts -> $(Device) ;
/proc/ioports -> $(Device) ;
/proc/scsi -> $(Device) ;
/proc/kcore -> $(Device) ;
/proc/self -> $(Device) ;
/proc/kmsg -> $(Device) ;
/proc/stat -> $(Device) ;
/proc/loadavg -> $(Device) ;
/proc/uptime -> $(Device) ;
/proc/locks -> $(Device) ;
/proc/meminfo -> $(Device) ;
/proc/misc -> $(Device) ;

from tripwire-open-source.

I'm going to close this enquiry for two reasons:
1 - I cannot reproduce the fault by either cloning the machine pre upgrade and upgrading or post upgrade
2 - I suspect there is an issue in the hostname system. One clone reports back $HOSTNAME as localhost, the other as the servername.tld. etc/hosts and /etc hostname are identical other than 1 char difference between images to make sure no network collisions ( e.g. server01, server02) There was an initial issue with tld file not found yesterday, resolved by rename a file to meet the tld ( localhost-local.key renames)

i am beginning to think there was a corruption in the cloned image as repeating the process from yesterday leaves me no errors.

sorry to bug you - will use the init --verbose options next time. Again thanks for reaching out.

from tripwire-open-source.