Security Design

Samhain
Prev |  | Next

# Chapter 11. Security Design

# 11.1. Usage

It is recommended to:

- compile a static binary (not linked to shared libraries), using the configure option --enable-static if possible (not possible on Solaris — this is a Solaris problem, not a problem of samhain)

- strip the binary (on i386 Linux/FreeBSD, also use the provided sstrip utility: strip samhain && sstrip samhain). This will help somewhat against intruders that try to run it under a debugger ...

  | Note
  | make install will always strip the excutables. Trying to strip again by hand may corrupt the executable.

- use signed database/configuration files using the configure option --with-gpg=PATH_TO_GPG, and compile in the fingerprint of the signing key ( --with-fp=...)

- take a look at the stealth options - while 'security by obscurity' only is a very bad idea, it certainly helps if an intruder does not know what defenses you have in place

If you use a precompiled samhain executable (e.g. from a binary distribution), in principle a prospective intruder could easily obtain a copy of the executable and analyze it in advance. This will enable her/him to generate fake audit trails and/or generate a trojan for this particular binary distribution.

For this reason, it is possible for the user to add more key material into the binary executable. This is done with the command:

samhain --add-key=`key@/path/to/executable`

This will read the file `/path/to/executable`, add the key key, which should not contain a '@' (because it has a special meaning, separating key from path), overwrite any key previously set by this command, and write the new binary to the location `/path/to/executable.out` (i.e. with .out appended). You should then copy the new binary to the location of the old one (i.e. overwrite the old one).

Prev | Home | Next
Method B: The native package manager |  | Integrity of the executable