Obviously, a security application should not open up security holes by itself. Therefore, an inportant aspect in the development of samhain has been the security of the program itself. While samhain comes with no warranty (see the license), much effort has been invested to identify security problems and avoid them.
As the client requires root privileges, while the server does not, the clients has no open socket to listen on the network. Consequently, all client/server connections are initiated by the client.
To avoid buffer overflows, only secure string handling functions are used to limit the amount of data copied into a buffer to the size of the respective buffer (unless it is known in advance that the data will fit into the buffer).
On startup, the timezone is saved, and all environment
variables are set to zero thereafter. Signal handlers,
timers, and file creation mask are reset, and the core dump
size is set to zero. If started as daemon, all file
descriptors are closed, and the first three streams are
opened to
/dev/null
.
If external programs are used (in the entropy gatherer,
if
/dev/random
is not
available), they are invoked directly (without using the
shell), with the full path, and with a limited environment
(by default only the timezone). Privileged credentials are
dropped before calling the external program.
With respect to its own files (configuration, database, the log file, and its lock), on access samhain checks the complete path for write access by untrusted users. Some care has been taken to avoid race conditions on file access as far as possible.
Critical information, including session keys and data read from files for computing checksums, is kept in memory for which paging is disabled (if the operating system supports this). This way it is avoided that such information is transfered to a persistent swap store medium, where it might be accessible to unauthorized users.
Random numbers are generated from a pseudo-random
number generator (PRNG) with a period of 2^88 (actually by
mixing the output from three instances of the PRNG). The
internal state of the PRNG is seeded from a strong entropy
source (if available,
/dev/random
is used, else
lots of system statistics is pooled and mixed with a hash
function). The PRNG is re-seeded from the entropy source at
regular intervals (one hour).
Numbers generated from a PRNG can be predicted, if the internal state of the PRNG can be inferred. To avoid this, the internal state of the PRNG is hidden by hashing the output with a hash function.