samhain file integrity scanner | online documentation


Frequently Asked Questions for Samhain


Rainer Wichmann

FAQ Revised: Wednesday 14 January 2015 20:41:15

Table of Contents

1. Most frequently
2. Build and install
3. File checking
4. Client/Server
5. Email
6. Misc
7. Database

1. Most frequently

1.1. Owner not trustworthy / Group writeable and member not trustworthy
An untrusted user (might be an untrusted group member for group writeable files/directories) owns or can write to an element in the path listed in the error message. This concerns the configuration file, the log file, and the database file. The offending element in the path is identified as obj=/xxx in the error message. To fix the problem, see next entry.

1.2. samhain exits with the message "Untrusted path" for config/log/pid/database files
Paths to critical files (e.g. the configuration file) must be writeable by trusted users only. If a path element is group writeable, all group members must be trusted. By default, only root and the (effective) user of the program are trusted. To add trusted users, use the compile time option 
$ ./configure --with-trusted=0,...
or the configure file option: 
[Misc]
TrustedUser=username
If the path to the configuration file itself is writeable by other users than root and the effective user these must be defined as trusted already at compile time.

1.3. It does not log anything / Can't stop logging to console
(1) There is a section in the manual dealing with logging and filtering.
(2) To log to the console: 
$ samhain -p info ...
or in the configuration file: 
[Log]
PrintSeverity=info
To stop logging to the console: 
$ samhain -p none ...
or in the configuration file: 
[Log]
PrintSeverity=none
Defining /dev/null as console device works as well, but is a bad idea, because samhain will open the device and write (i.e. it is a very inefficient method).

1.4. Client cannot self-resolve, but nslookup works fine
  • Nslookup is a program to query Internet domain name servers.
  • Applications (like samhain) are not supposed to query DNS servers directly. Rather, they are supposed to query the resolver library that:
    • is provided by the operating system,
    • configured by the system administrator,
    • may use several different method to determine host names, as configured in /etc/nsswitch.conf, and
    • usually is configured to give precedence to the /etc/hosts file.
  • Therefore, whether nslookup gives correct answers may be completely irrelevant. For self-resolving the own hostname, the resolver library probably will use /etc/hosts, rather than querying a DNS server.

Below you can find some examples of good and bad /etc/hosts files: 

        # CORRECT
	#
        127.0.0.1  localhost
        xxx.xxx.xxx.xxx myhost.mydomain.tld  myhost

        # CORRECT
	#
        127.0.0.1  localhost.localdomain localhost
        xxx.xxx.xxx.xxx myhost.mydomain.tld  myhost

        # BAD
	#
        127.0.0.1  myhost.mydomain.tld  localhost
        xxx.xxx.xxx.xxx myhost.mydomain.tld  myhost

        # BAD
	#
        127.0.0.1  localhost myhost
        xxx.xxx.xxx.xxx myhost.mydomain.tld  myhost


1.5. Server logs hostname instead of FQDN (or vice versa)
The default is to log the hostname only, if you want the FQDN then there is an option for the server configuration: 
        [Misc]
	SetStripDomain = true / false


2. Build and install

2.1. [Fedora Core] Cannot compile with --enable-khide
The Fedora Core kernel is patched to unconditionally deny reading from /dev/kmem. Compiling the stealth kernel modules is not possible under these circumstances.

2.2. [Fedora Core] Cannot compile with --with-kcheck
The Fedora Core kernel is patched to unconditionally deny reading from /dev/kmem. Checking the kernel for the presence of rootkits is not possible under these circumstances.

2.3. "make" loops infinitely !
This may happen (e.g. when building via NFS for multiple architectures) if the relative timestamps in the source directory are wrong (time not in sync on different machines) or some intermediate target is unusable (up-to-date, but built for a different OS). Use "touch * && make distclean" in the source directory to recover.

2.4. Why does static compiling (--enable-static) on Solaris fail ?
Ingo Rogalsky has provided the following information: It isn't possible to link Samhain statically with Solaris. This is a Solaris issue (see Sun Infodoc ID12624) and not a samhain problem.

2.5. Compilation fails with '/usr/bin/ld: cannot find -lnss_files'
For Linux, this is a known problem with --enable-static if you compile in MySQL support. The problem is that the mysql_config that comes as part of the MySQL distribution script incorrectly lists dependencies on the libnss_files and libnss_dns libraries which are only available as shared libraries, so the linker cannot find the static libraries. You can check this by inspecting the output of mysql_config --libs. The version of mysql_config that comes with the RedHat mysql RPM (RedHat 9) does not have this bug; the one distributed by the MySQL people has. You can fix the problem by editing mysql_config: search for the client_libs variable, and remove all instances of -lnss_files and -lnss_dns.

2.6. The executable is corrupted after installation
The executable will get stripped during the installation. On suitable systems (i386 Linux/FreeBSD currently), additionally the "sstrip" utility (copyright 1999 by Brian Rait