systrace(1) - NetBSD Manual Pages

SYSTRACE(1)             NetBSD General Commands Manual             SYSTRACE(1)


NAME

     systrace -- generate and enforce system call policies


SYNOPSIS

     systrace [-AaCitUu] [-c user:group] [-d policydir] [-f file] [-g gui]
              [-p pid] command ...


DESCRIPTION

     The systrace utility monitors and controls an application's access to the
     system by enforcing access policies for system calls.  The systrace util-
     ity might be used to trace an untrusted application's access to the sys-
     tem.  Alternatively, it might be used to protect the system from software
     bugs (such as buffer overflows) by constraining a daemon's access to the
     system.  Its privilege elevation feature can be used to obviate the need
     to run large, untrusted programs as root when only one or two system
     calls require root privilege.

     The access policy can be generated interactively or obtained from a pol-
     icy file.  Interactive policy generation will be performed by the
     ``notification user agent'', normally xsystrace(1), unless text mode is
     specified via -t.

     When running in ``automatic enforcement'' mode, operations not covered by
     the policy raise an alarm and allow a user to refine the currently con-
     figured policy.

     The options are as follows:

     -A       Automatically generate a policy that allows every operation the
              application executes.  The created policy functions as a base
              that can be refined.

     -a       Enables automatic enforcement of configured policies.  An opera-
              tion not covered by policy is denied and logged via syslog(3).

     -C       Run systrace in cradle mode; if a cradle server is not running,
              one is launched.  This decouples UIs from systrace, allowing for
              re-attaching UIs.

     -c user:group
              Specifies the user and group that the monitored application
              should be executed with, which may be either non-negative inte-
              gers or names.  This is useful in conjunction with privilege
              elevation and requires root privilege.

     -d policydir
              Specifies an alternative location for the user's directory from
              which policies are loaded and to which changed policies are
              stored.

     -f file  The policies specified in file are added to the policies that
              systrace knows about.

     -g gui   Specifies an alternative location for the notification user
              interface.

     -i       Inherits the policy - child processes inherit policy of the par-
              ent binary.

     -p pid   Specifies the pid of a process that systrace should attach to.
              The full path name of the corresponding binary has to be speci-
              fied as command.

     -t       Uses text mode to ask for interactive policy generation.

     -U       Ignore user configured policies and use only global system poli-
              cies.

     -u       Do not perform aliasing on system call names.  Aliasing is
              enabled by default to group similar system calls into a single
              compound name.  For example, system calls that read from the
              file system like lstat() and access() are translated to
              fsread().

   POLICY
     The policy is specified via the following grammar:

        filter = expression "then" action errorcode logcode
        expression = symbol | "not" expression | "(" expression ")" |
            expression "and" expression | expression "or" expression
        symbol = string typeoff op cmdstring | "true"
        typeoff = /* empty */ | "[" number "]"
        op = "match" | "eq" | "neq" | "sub" | "nsub" | "inpath" | "re"
           | "topdir"
        action = "permit" | "deny" | "ask"
        errorcode = /* empty */ | "[" string "]"
        logcode = /* empty */ | "log"

     The cmdstring is an arbitrary string enclosed with quotation marks.  The
     errorcode is used to return an errno(2) value to the system call when
     using a deny action.  The values ``inherit'' and ``detach'' have special
     meanings when used with a permit rule for the execve system call.  When
     using ``inherit,'' the current policy is inherited for the new binary.
     With ``detach,'' systrace detaches from a process after successfully com-
     pleting the execve system call.

     The ask action specifies that the user should be prompted for a decision
     every time that the rule matches.

     The filter operations have the following meaning:

        match    Evaluates to true if file name globbing according to
                 fnmatch(3) succeeds.

        eq       Evaluates to true if the system call argument matches
                 cmdstring exactly.

        neq      This is the logical negation of eq.

        sub      Performs a substring match on the system call argument.

        nsub     This is the logical negation of sub.

        inpath   Evaluates to true if the system call argument is a subpath of
                 cmdstring.  Note that cmdstring must be an absolute pathname,
                 possibly with one trailing slash.

        re       Evaluates to true if the system call arguments matches the
                 specified regular expression.

        topdir   Evaluates to true if the system call argument is in a direc-
                 tory hierarchy under cmdstring.

     By appending the log statement to a rule, a matching system call and its
     arguments is logged to syslog(3).  This is useful, for example, to log
     all invocations of the execve system call.

     Policy entries may contain an appended predicate.  Predicates have the
     following format:

        ", if" {"user", "group"} {"=", "!=", "<", ">" } {number, string}

     A rule is added to the configured policy only if its predicate evaluates
     to true.

     The environment variables $HOME, $USER and $CWD are substituted in rules.
     Comments, begun by an unquoted `#' character and continuing to the end of
     the line, are ignored.


PRIVILEGE ELEVATION

     With systrace it is possible to remove setuid or setgid binaries, and use
     the privilege elevation feature instead.  Single system calls can be exe-
     cuted with higher privileges if specified by the policy.  For example,

        native-bind: sockaddr eq "inet-[0.0.0.0]:22" then permit as root

     allows an unprivileged application to bind to a reserved port.  Privilege
     elevation requires that the systrace process is executed as root.

     The following statements can be appended after the permit in a policy to
     elevate the privileges for the matching system call:

        as user
        as user:group
        as :group

     The effective uid and gid are elevated only for the duration of the sys-
     tem call, and are restored to the old values afterwards (except for the
     seteuid or setegid system calls).


FILES

     /dev/systrace    systrace device
     /etc/systrace    global systrace policies
     $HOME/.systrace  user specified policies, one per binary, with slashes in
                      the full pathname replaced by the underscore character.


EXAMPLES

     An excerpt from a sample ls(1) policy might look as follows:

       Policy: /bin/ls, Emulation: native
       [...]
          native-fsread: filename eq "$HOME" then permit
          native-fchdir: permit
       [...]
          native-fsread: filename eq "/tmp" then permit
          native-stat: permit
          native-fsread: filename match "$HOME/*" then permit
          native-fsread: filename eq "/etc/pwd.db" then permit
       [...]
          native-fsread: filename eq "/etc" then deny[eperm], if group != wheel


SEE ALSO

     systrace(4)


HISTORY

     The systrace utility first appeared in OpenBSD 3.2, and then in
     NetBSD 2.0.


AUTHORS

     The systrace utility was developed by Niels Provos.


BUGS

     Applications that use clone()-like system calls to share the complete
     address space between processes may be able to replace system call argu-
     ments after they have been evaluated by systrace and escape policy
     enforcement.

NetBSD 4.0                     September 3, 2005                    NetBSD 4.0