Systrace for Slackers

Ray Lai <ray@cyth.net>

What is Systrace? Why is Systrace?

Systrace:

Records program behavior into policies
Confines programs to that behavior
Any deviation from behavior is denied and logged
Web browser connecting to chat rooms?

Systrace Can Protect Programs

Chat clients
Web servers
Commercial software

Network programs are exposed to malicious traffic all day long. Web and FTP servers, peer-to-peer network servers, and chat clients are constantly under attack.

Nobody knows what binary-only executables are really doing. Is notepad phoning home? Even with source, configure scripts can be trojaned and take over a system when you do a “make install” as root.

Systrace Policies

Systrace uses policies to confine programs
Mostly consist of permit lines
Anything not permitted is denied

Systrace Policies

Permit or deny system calls
Important ones: execve(2), connect(2), bind(2), fswrite(2), and fsread(2)
Others are needed for normal operation and should be permitted.

Systrace policies consist of system calls followed by a “permit” or “deny”. The common important ones are filesystem read and writes, network connections, and program executions. Pay attention to these!

Most of the other system calls cannot be denied without changing program execution and must be permitted.

Filesystem Rules

Typical Shell Access


native-fsread: true then permit
native-fswrite: filename match "$HOME" then permit
native-fswrite: filename match "/tmp" then permit

Filesystem Rules

Restricted Shell Access


native-fsread: filename match "$HOME" then permit
native-fsread: filename match "/home" then deny[eperm]
native-fsread: true then permit

Notice that first matching rule wins.

Program Execution

Permit Running All System Binaries


native-execve: filename match "/bin" then permit
native-execve: filename match "/sbin" then permit
native-execve: filename match "/usr/bin" then permit
native-execve: filename match "/usr/games" then permit
native-execve: filename match "/usr/sbin" then permit

Inherited Program Execution

Share Policy File


native-execve: filename match "/bin" \
    then permit[inherit]
native-execve: filename match "/sbin" \
    then permit[inherit]
native-execve: filename match "/usr/bin" \
    then permit[inherit]
native-execve: filename match "/usr/games" \
    then permit[inherit]
native-execve: filename match "/usr/sbin" \
    then permit[inherit]

Gaim

Permit AIM and DNS Connections.


native-connect: sockaddr match "inet-*:5190" \
    then permit
native-connect: sockaddr eq "inet-[127.0.0.1]:53" \
    then permit

Web Browser

Permit HTTP, HTTPS, and DNS Connections. Ask All Others.


native-connect: sockaddr match "inet-*:443" \
    then permit
native-connect: sockaddr match "inet-*:80" \
    then permit
native-connect: sockaddr eq "inet-[127.0.0.1]:53" \
    then permit
native-connect: sockaddr eq "inet-*" then ask

Web Server

Permit listening to HTTP port.


native-bind: sockaddr match "inet-*:80" then permit

Systracing Programs

Automatically generate a policy:
# systrace -Ai firefox
Surf the web a bit…
Quit firefox

Policy Management

Sort policies
Inherit mode
Generalize libraries, paths, and IPs
Use version control

Policies can be overwhelming if everything were automatically generated. Sorting clarifies the policy immensely. I use sort -k1,1 -k4 to sort the policies first by system call, then by parameter (usually filenames).

Libraries, pathnames, and IP addresses can usually be generalized using globbing rules.

Version control keeps policies from getting out of hand. Every new system call added can be identified easily by diffing the current version with an older version.

Alternatives

Physical Separation
Jail
System Emulators (Xen, VMWare)
Privilege Separation (chroot, drop privileges)
Cerb

We can use the jail facility, found in FreeBSD. This requires installing and configuring the operating system for every jail instance. It also gives attackers the full tool set found in an operating system.

We can use system emulators, such as Xen and VMWare. These also require installing and configuring operating systems for every instance and gives attackers all the tools provided by the operating system. There is also overhead from emulating a machine.

We can use the privilege separation techniques used by OpenBSD to chroot into empty directories and drop all privileges. This requires source code change, which can be very simple or very difficult (look at OpenSSH).

Conclusion

Pros:

Prevent exploits
Run unknown programs
Minimize privileges
Easy to understand policies

Systrace prevents programs from being exploited, enables one to run untrusted binaries with less risk, reduce the amount of code that is run as root, and is controlled by simply policies.

Conclusion

Cons:

Initial learning curve
Underused and misunderstood
Tedious policy generation
Inactive development

Conclusion

However:

Very powerful already
Not as hard as it seems
Open source

Thanks

Jen for napping in the audience
Dug Song, George, Ike, and Okan for inspiration, criticism, and putting up with me
Niels Provos for writing Systrace

More Information

systrace.org
monkey.org/~jose/software/stsh/
cyth.net/~ray/systrace-talk/

NYCBUG, March 2006