5. Log file

Trusted users

TrustedUser= username

If some element in the path to the log file is writeable by someone else than root or the effective user of the process, you have to include that user in the list of trusted users(unless their UIDs are already compiled in).

Separate log files for clients

UseSeparateLogs= yes/no

Only relevant on the server. Use a separate log file for (reports from) each client. The root name of these log files will be the same as the main log file, with the client name appended.

5.1. The log file and its integrity

The log file is named samhain_log by default, and placed into /var/log by default (name and location can be configured at compile time). If samhain has been compiled with the ./configure --enable-xml-log option, it will be written in XML format.

[Note]Note

If you have compiled for stealth ( Chapter 10 ), you won't see much, because if obfuscated, then both a 'normal' and an XML logfile look, well ... obfuscated. Use samhain -jL /path/to/logfile to view the logfile.

The log file is created if it does not exist, and locked by creating a lock file, which has the same path as the logfile, with a ".lock" appended. The lock file holds the PID of the process, which allows samhain to recognize and remove a stale lock if there is no process with that PID.

On the log server, it is possible to use separate log files for individual clients. This can be enabled with UseSeparateLogs= yes/no in the Misc section of the server configuration file. No locking will be performed for client files (only one instance of the server can listen on the TCP port, thus there will be no concurrent access).

The directory where the logfile and its lock file are located must be writeable only by trusted users (see Section 10.1 ). This requirement refers to the complete path, i.e. all directories therein. By default, only root and the effective user of the process are trusted.

Audit trails (sequences of messages from individual runs of samhain ) in the log file start with a [SOF] marker. Each message is followed by a signature, that is formed by hashing the message with a key.

The first key is generated at random, and sent by e-mail, encrypted with a one-time pad as described in the previous section on e-mail. Further keys are generated by a hash chain (i.e. the key is hashed to generate the next key). Thus, only by knowing the initial key the integrity of the log file can be assured.

The mail with the key looks like:

	  -----BEGIN MESSAGE-----  
	  message    
	  -----BEGIN LOGKEY----- 
	  Key(48 chars)[timestamp]     
	  -----BEGIN SIGNATURE----- 
	  signature
	  ID TRAIL_ID:hostname 
	  -----END MESSAGE-----  
	
[Tip]Integrity verification

To verify the log file's integrity, a convenience function is provided:

samhain -L /log/file/path

When encountering the start of an audit trail, you will then be asked for the key (as sent to you by e-mail). You can then: (i) hit return to skip signature verification, (ii) enter the key (without the appended timestamp), or (iii) enter the path to a file that contains the key (e.g. the mail box).

If you use option (iii), the path must be an absolute path (starting with a '/', not longer than 48 chars. For each audit trail, the file must contain a two-line block with the -----BEGIN LOGKEY----- line followed by the line ( Key(48 chars)[timestamp]) from the mail. Additional lines before/after any such two-line block are ignored (in particular, if you collect all e-mails from samhain in a mailbox file, you can simply specify the path to that mailbox file).

[Warning]CAVEATS

Verification will fail, if the compiled-in key of the verifying executable is different from the one that generated the message(s) (see Section 2 ).

If you use a pre-compiled executable from some binary distribution, be sure to read Section 2 carefully.