    tt(USE) directives provide s() with arguments which
may be conditional to a certain installation. The following bf(USE) directives
are supported:
    itemization(
    it() bf(USE BASE) tt(basedirectory)

        bf(BASE) defines the directory from where s() operates. All relative
path specifications in this section of the policy file are interpreted
relative to bf(BASE). em(By default) this is the directory where s() was
started.

    If necessary, s() creates all bf(BASE) and other directories below
tt(BASE). 

    Example: using the specification
        verb(    USE BASE /root/client)
    results in all information generated by s() being written in or below the
directory tt(/root/client).

    it() bf(USE DD) tt(<dd>)nl()
        The bf(DD) specification uses tt(/bin/dd) as default, and defines the
location of the bf(dd)(1) program, both on the server and on the client. The
bf(DD) program is used to copy files between the client and the monitor
without creating separate ssh-connections. The bf(DD) program is only
used by s() for the tt(PUT) and tt(GET) commands, described below.

    Example showing the default:\
        verb(    USE DD /bin/dd)

    it() bf(USE DIFF) tt(path-to-diff)

        The bf(DIFF) specification uses tt(/usr/bin/diff) as default,
and defines the location of the bf(diff)(1) program. The
bf(diff)(1) program is used to compare a formerly created logfile of an
integrity check to a newly created logfile.

    Example showing the default:
        verb(    USE DIFF /usr/bin/diff)
    
    it() bf(USE DIFFPREFIX) tt(<prefix>)

        The bf(DIFFPREFIX) specification defines the size of the prefix added
by the tt(DIFF) command to lines produced by commands executed through s().
The default tt(/usr/bin/diff) program prefixes lines by either `tt(> )' or
`tt(< )'. The default value for tt(<prefix>) therefore equals 2.

    Example showing the default:
        verb(    USE DIFFPREFIX 2)

    it() bf(USE EMAIL) tt(address)

        The bf(EMAIL) specification defines the email-address to e-mail the
client's integrity scan report to. Mail is only sent when information has
changed.

    Example showing the default:
        verb(    USE EMAIL root)

    it() bf(USE MAILER) tt(mailer)

        The bf(MAILER) specification defines the program that is used to send
the mail to the bf(EMAIL)-address. By default this is bf(/usr/bin/mail)(1). 
The bf(MAILER) program is called as follows:
        verb(    MAILER  MAILARGS EMAIL)
    (tt(MAILARGS): see below). The information to be mailed is read from
tt(MAILER)'s standard input stream.

    Example showing the default:
        verb(    USE MAILER /usr/bin/mail)

    it() bf(USE MAILARGS) tt(arguments)
        The bf(MAILARGS) specification defines the arguments to be
to be passed to the tt(MAILER) program. By default this is 
        verb(    USE MAILARGS -s "STEALTH scan report") 
    Note that blanks may be used in the subject specification: use double or
single quotes to define elements containing blanks. Use tt(\") to use a double
quote in a string that is itself delimited by double quotes, use tt(\') to use
a single quote in a string that is itself delimited by single quotes. 

    Subtlety: in constructions like 
        verb(    USE MAILARGS " 't was brillig " and 't went well)
    the following arguments are passed to tt(MAILER):
        itemization(
        it() tt(" 't was brillig ")
        it() tt(and)
        it() tt('t)
        it() tt(went)
        it() tt(well)
        )
    So, when single- and double-quoted strings overlap, the first string is
taken as a string, and the information beyond the first string is thereupon
interpreted. 

    it() bf(USE REPORT) tt(<file-spec>)nl()
        bf(REPORT) defines the name of the reportfile. Information is always
appended to this file. At each s() integrity scan a em(time marker line) is
written to the report file. Only when (in addition to the marker line)
additional information is appended to the report file the added contents of
the report file are mailed to the mail address specified in the bf(USE EMAIL)
specification. When a relative file specification is used it is interpreted a
location relative to the tt(USE BASE) specification.nl()
    Example showing the default:nl()
    tt(USE REPORT report)

    it() bf(USE SH) tt(<sh>)nl()
        The bf(SH) specification uses tt(/bin/sh) as default, and defines the
command shell used by the monitor to execute commands on itself. This must be
an absolute path specification.nl()
    Example showing the default:nl()
    tt(USE SH /bin/sh)

    it() bf(USE SSH) tt(<user>)nl()
        bf(The SSH specification has no default), and em(must) be
specified. This must be an absolute path specification.  

    Assuming the client em(trusts) the monitor (which is after all what this
program is all about, so this should not be a very strong assumption),
preferably the public ssh key of the monitor should be placed in the
client's root tt(.ssh/authorized_keys) file, granting the monitor root access
to the client. Root access is normally needed to gain access to all
directories and files of the client's file system.

    In practice, connecting to an account using the bf(sh)(1) shell is
preferred. When another shell is already used by that account, one should make
sure that its shell doesn't define its own redirections for standard input
and standard output. One way to accomplish that is for force the execution of
tt(/bin/sh) in the bf(USE SSH) specification.

    An example of an tt(SSH) specification to scan a localhost is:
        verb(
    USE SSH root@localhost -T -q                # root's shell is /bin/sh)

    The same, now explicitly using tt(/bin/bash):
        verb(
    USE SSH root@localhost -T -q exec /bin/bash # root uses another shell)

    Alternatively, tt(--noprofile) can be specified to prevent any
profile-initialization: 
        verb(
    USE SSH root@localhost -T -q exec /bin/bash --noprofile)    
    )

    In some installations s() is used to inspect the monitor itself, even
though this is em(not) recommended, as it breaks one of the main reasons for
s()'s existence. But in those situations (so, where s() is used to monitor the
integrity of the tt(localhost)), tt(/bin/bash) could be specified at the
tt(USE SSH) directive. For example:
        verb(    # For stealth inspecting localhost:
        USE SSH /bin/bash --noprofile)
