Welcome to s(). The program s() implements a file integrity
scanner. The acronym s() can be expanded to

center(
nsect(SSH-based Trust Enforcement Acquired through a Locally Trusted Host.)
)

This expansion contains the following key terms:

    itemization(
    it() tt(SSH-based): The file integrity scan is (usually) performed over an
ssh-connection. Usually the computer being scanned (called the em(client)) and
the computer initiating the scan (called the tt(monitor)) are different
computers. 
    it() The client should accept incoming ssh-connections from the
monitor. The monitor doesn't have to (and shouldn't, probably).
    it() tt(Trust Enforcement): following the scan, `trust' is enforced in the
client, due to the integrity of its files.
    it() tt(Locally Trusted Host): the client apparently trusts the monitor
to use an ssh-connection to perform commands on it. The client therefore
em(locally trusts) the monitor. Hence, em(locally trusted host).
    )

    s() is based on an idea by em(Hans Gankema) and em(Kees Visser),
both at the Center for Information Technology of the University of Groningen.

    s()'s main task is to perform file integrity tests. However, the
testing will leave virtually no sediments on the tested computer. Therefore,
s() has em(stealthy) characteristics. I consider this an important
security improving feature of s().

    The monitor itself only needs two kinds of outgoing services:
bf(ssh)(1) to reach its clients, and some mail transport agent (e.g.,
bf(sendmail)(1)) to forward its outgoing mail to some mail-hub.

    Here is what happens when s() is run:
    itemization(
    it() First, the em(policy) file is read. For each client a policy file is
defined, specifying the actions to be performed, and specifying the values of
several variables used by s().

    it() If the command-line option tt(--daemon <uds>) is specified, s()
runs as a daemon process, using the Unix Domain Socket (tt(<uds>)) for
communication with s() processes running in IPC mode.

If access to the Unix Domain Socket defined by Stealth running in daemon mode
should be restricted, it can be defined in a directory with is only accessible
to the user running Stealth (this will often be the root-user).

When running in daemon mode, tt(--repeat <seconds>) may be specified to rerun
the integrity scan every tt(<seconds>) seconds. If an integrity scan is being
performed when, according to the repeat interval the next integrity scan is
due, then the current scan is first completed. Once completed, the next
integrity scan will be performed after tt(seconds) seconds.

    it() Next, the monitor opens a command shell on the client using
bf(ssh)(1), and a command shell on the monitor computer itself using
bf(sh)(1).

    it() Once the command shells are available, commands defined in the policy
file are executed in their order of appearance. Examples are given
below. Normally, return values of the programs are tested. When return values
are to be tested s() terminates when a non-zero return value is sensed. If
this happens, a message stating the reason why s() terminated is written to
the report file (and into the mail sent by s()). In some cases (e.g., when the
report file could not be written), the message is written to the standard
error stream.

    it() Very often integrity tests can be controlled using bf(find)(1),
calling programs like bf(ls)(1), bf(sha1sum)(1) or its own tt(-printf) method
to produce file-integrity related statistics. Most of these programs write
file names at the end of generated lines. This characteristic is used by one
of s()'s internal routines to detect changes in the generated output. Such
changes could indicate some harmful intent, like an installed em(root-kit).

    it() When changes are detected, they are logged in a em(report file), to
which information is always appended. S() never reduces the report file's size
or rewrites its contents. When information is added to the report file (beyond
a plain time stamp) the newly added information is e-mailed to a configurable
e-mail address for further (human) processing. Usually the e-mail is sent to
the systems manager of the tested client. S() follows the `dark cockpit'
approach in the sense that no mail is sent when no changes were detected.

    it() Report and other log-files may safely be rotated between a pair of
tt(--suspend) and tt(--resume) commands (see below at the section
ref(ROTATE)).
    )

    Instead of running in daemon mode, s() may also run in `foreground' mode.
In foreground mode the option tt(--daemon) is not specified. When running in
foreground mode s() either performs one integrity scan (and terminates) or, if
the tt(--repeat) option has been specified, it repeatedly performs integrity
scans, at intervals determined by the tt(--repeat) and tt(--random-interval)
options. When tt(--repeat) is specified with s() running in foreground mode a
prompt is shown (i.e., `tt(? )') with  s() terminating after pressing the
tt(Enter)-key.

    Alternatively, s() may run in `inter process communication' mode (IPC
mode). IPC mode is characterized by using one of the command-line options
tt(--reload, --rerun, --suspend, --resume) or tt(--terminate). In IPC-mode s()
communicates with an existing s() daemon, using the Unix Domain Socket defined
by the s() daemon. These options require but one argument: the location of the
Unix Domain Socket defined by a running s() daemon.
    itemization(
    it() When started using the tt(--reload <uds>) command-line option, the
stealth daemon that created the Unix Domain Socket reloads its policy file
(and skip-file), immediately followed by another integrity scan;
    it() When started using the tt(--rerun <uds>) command-line option, the
stealth daemon that created the Unix Domain Socket performs another integrity
scan;
    it() When started using the tt(--terminate <usd>) command-line option, the
stealth daemon that created the Unix Domain Socket terminates.
    )

    The options tt(--suspend) and tt(--resume) (see section ref(ROTATE)) were
implemented to allow safe rotations of s()'s log-files.











