Systrace enforces system call policies for applications by constraining the application's access to the system. The policy is generated interactively. Operations not covered by the policy raise an alarm and allow a user to refine the currently configured policy.
For complicated applications, it is difficult to know the correct policy before running them. Initially, Systrace notifies the user about all system calls that an applications tries to execute. The user configures a policy for the specific system call that caused the warning. After a few minutes, a policy is generated that allows the application to run without any warnings. However, events that are not covered still generate a warning. Normally, that is an indication of a security problem.
With Systrace untrusted binary applications can be sandboxed. Their access to the system can be restricted almost arbitrarily. Sandboxing an application that is only available as binaries is the only sensible solution as it is not possible to directly analyze what they are designed to do. However, constraining the system calls large open-source applications are allowed to execute is useful too as it is very difficult to determine
Intrusion Detection
With Systrace it is possible to monitor daemons on remote machines and generate warnings at a central location. As these warnings indicate operations not covered by existing policy, it is possible to detect intrusions and prevent them from succeeding. For example, a web server or ftp server can be monitored that way.
Non-Interactive Policy Enforcement
Once a policy has been generated, Systrace can enforce it automatically without user interaction. System calls not covered by the existing policy are denied. For example, a shell provider can enforce policy of user shells and executed commands with Systrace.
Policy Example
The following example illustrates a simple policy for the ls binary. If ls attempts to list files in /etc, Systrace disallows the access and /etc does not seem to exist. Listing the contents of /tmp works normally, but trying to ls /var generates a warning.
Policy: /bin/ls, Emulation: native
native-munmap: permit
[...]
native-stat: permit
native-open: filename match "/usr/*" and oflags sub "ro" then permit
native-open: filename eq "/tmp" then permit
native-open: filename eq "/etc" then deny[enotdir]
native-fchdir: permit
native-fstat: permit
native-fcntl: permit
[...]
native-close: permit
native-write: permit
native-exit: permit
