systrace man page on OpenBSD

Man page or keyword search:  
man Server   11362 pages
apropos Keyword Search (all sections)
Output format
OpenBSD logo
[printable version]

SYSTRACE(1)		   OpenBSD Reference Manual		   SYSTRACE(1)

NAME
     systrace - generate and enforce system call policies

SYNOPSIS
     systrace [-AaCeitUuV] [-c user:group] [-d policydir] [-E logfile]
	      [-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
     utility might be used to trace an untrusted application's access to the
     system.  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
     policy 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
     configured 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
	      operation not covered by policy is denied and logged via
	      syslog(3), or to stderr if the -e flag is specified.

     -C	      Run systrace in cradle mode; currently, when multiple processes
	      are started with systrace protection, each systrace starts its
	      own UI (user interface) process.	Cradle mode allows a user to
	      attach all systrace processes to one UI.	This may be useful,
	      for example, in scenarios where systrace is being heavily used.
	      If a cradle server is not running, one is launched.

     -c user:group
	      Specifies the user and group that the monitored application
	      should be executed with, which may be either non-negative
	      integers 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.

     -E logfile
	      Logs all policy violations or specifically logged system calls
	      to logfile.

     -e	      Specifies to log to stderr instead of syslog(3).

     -f file  The policies specified in file are added to the policies that
	      systrace knows about.  The dirname in the policy may contain an
	      "*" to match any possible pathname.  The wildcard is removed
	      from the policy database the first time that a filename matches.

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

     -i	      Inherits the policy after a call to execve(2).  If this option
	      is not specified, a new program will get its own policy.

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

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

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

     -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().

     -V	      Prints the version number of systrace.

   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 "match" cmdstring |
	    string typeoff "eq" cmdstring | string typeoff "neq" cmdstring |
	    string typeoff "sub" cmdstring | string typeoff "nsub" cmdstring |
	    string typeoff "inpath" cmdstring | string typeoff "re" cmdstring |
	    "true"
	typeoff = /* empty */ | "[" number "]"
	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
     completing 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.

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

     By appending the log statement to a rule, a matching system call and its
     arguments are logged.  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
     executed 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
     system 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)

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
     arguments after they have been evaluated by systrace and escape policy
     enforcement.

OpenBSD 4.9			 May 31, 2007			   OpenBSD 4.9
[top]

List of man pages available for OpenBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net