Table of Contents
samhain 4.0 introduces a set of new features to allow seamless integration with an existing change control process. This feature set has been drafted as the result of a workshop, and is designed to meet some key criteria:
The whole procedure can be run in an automated way, i.e. it can be executed by scripts and without human intervention, once a list of affected files is available. It is expected that the change control process will yield the list of affected files from the development or quality assurance stage.
The feature set provided should be rather generic and not tied to any particular change control software.
Immediately before a change is implemented, the affected files can be tested for their integrity. I.e. it can be verified that the system is in a known-good state before the change is put into effect.
After a change is implemented, the baseline, i.e. the database of known-good file signatures, can be updated.
The approval of the change(s) performed can be securely communicated to the running Samhain daemon on the affected machine(s), such that a subsequent file integrity check will raise no alerts.
The following list shows the use cases that were considered, and how they may be handled.
This case is best handled by a comple re-initialisation of the baseline database. The running Samhain daemon performs an on-demand file system scan immediately before the machine is taken offline to ensure a valid state, the database will be initialized after the patch has completed, and the Samhain daemon will re-start when the machine goes online again.
sh# kill -s TTOU $( cat /var/run/samhain.pid )It is possible to perform a wait-on-completion (with an optional timeout) that provides an exit status to indicate whether the file system scan found any inconsistencies:
sh# samhain -w <timeout>
sh# samhain -t init
# Delay database download at startup by N seconds StartupLoadDelay = N
In this case, because the package is not installed yet a "pre-flight" scan may be deemed unneccessary. After installation of the package, a DeltaDB (delta database) containing the added files will be generated and transferred to the server. There, it will be merged into the existing baseline database.
The approval of the file system changes will be done by the server asking the client to download the DeltaDB. For security, there is no client-side mechanism to trigger an approval of the file system changes.
sh# samhain --outfile <DeltaDB> --create-database <file_list>
One pathname per line, optionally preceded by a '+' (plus) sign which, if present, indicates that the content of the file should be stored. The configuration file will NOT be read, and the policy recorded in the baseline database will be ReadOnly.
sh# beltane_update --merge <UUID> --update <baseline_file>
sh# yulectl -c DELTA:<UUID> <client_fqdn>
|Location and naming scheme|
The DeltaDB must be named
# Maximum retry count SetDeltaRetryCount = N # Time in seconds between re-tries SetDeltaRetryInterval = N
This case differs from Case II insofar as there are already installed files, and therefore it is desirable to verify the integrity of those files before the change is put into effect. To perform this check, on the server a PartialDB (partial database, containing only data for affected files) is generated from the full baseline database. This PartialDB is then transferred to the client and used to perform a verification scan.
If the affected files are found to be in a consistent state, the procedure continues as in Case II then.
sh# samhain --outfile <PartialDB> --list-filter <list_file> --binary -d <baseline_file>
sh# samhain --verify-database <PartialDB>