Ali Polatel

To compensate for network latency during playing chess games over internet, internet chess servers like Fics and Icc use proprietary protocols called timeseal and timestamp. They distribute statically linked stripped binaries which acts like a bridge between chess clients and the chess server.

To make sure these tools don’t do anything nasty, I use sydbox to sandbox them. Sydbox’ master extends network whitelisting support for network mode deny. So I use it like:

alip@harikalardiyari> cat ~/bin/timeseal
#!/bin/sh
# vim: set sw=4 et sts=4 tw=80 :

SYDBOX_NO_CONFIG=1 \
SYDBOX_NET_WHITELIST=inet://69.36.243.188:23 \
sydbox -N -M deny -- \
"$HOME"/bin/ics/timeseal.Linux-i386 69.36.243.188 23
alip@harikalardiyari>

SYDBOX_NO_CONFIG makes sydbox not read its configuration file and SYDBOX_NET_WHITELIST adds the address, in this case freechess.org, to the network whitelist.

Now that addpredict is dead, the next thing to implement for sydbox is proper network sandboxing. I’ve been working for the past three days to do that.

First of all let’s define what we want:

• A way to intercept socket() family calls.
• The ability to deny only non-local connections.
• The ability to deny connect()’s to only addresses that were bind()‘ed by children that were running under the same sydbox instance.
• Ability to whitelist certain addresses.

The first is easy. We already have a framework for intercepting many system calls and adding support for socket() wasn’t a problem. The only problem is on architectures which has the socketcall() system call and implement all other calls on top of this single system call, we need to decode this socketcall() into it’s subcalls. So we need two functions trace_decode_socketcall and trace_get_addr. Implementing those were easy because strace already has similar functions.

Now that we can intercept socket calls the next step is to deny only non-local connections. This means just checking the address of the connection if it matches 127.0.0.1 or ::1. Simple and efficient.

The third step is somewhat complicated. We have to check the return value of bind calls and if they succeeded, note these addresses and corresponding ports. This means a form of whitelist is required.

Having implemented the whitelist for step 3, it was easy to expand it to take its elements from user configuration file or magic commands.

It’s all done! Here’s how it looks like in the configuration file:

[main]
...
# whether sydbox should do network sandboxing
# defaults to false
network = false
...
# Network specific options are specified in the net group
[net]
# Network sandboxing default
# One of allow, deny, local
# Defaults to allow
default = allow

# Whether connect(2) requests should be restricted to addresses that were
# bind(2)'ed by one of the parents.
# Defaults to false
restrict_connect = false

# Additional addresses to be allowed when restrict_connect is set.
# This is a list of addresses in one of the possible forms:
# unix:///path/to/socket
# inet://ipv4_address:port
# inet6://ipv6_address:port
whitelist = unix:///var/run/nscd/socket

In addition to that there are magic commands so that the package mangler can change those options at runtime. See the manual page for more information.

Update : Fixed links thanks to cuerty.

addpredict is one of the commands I hate. There are many reasons for this. First of all it’s not a real fix, just a hack. If an exheres needs addpredict, it usually means the package needs fixing.

Second reason is it’s really difficult to implement and it’s error prone. To implement addpredict using ptrace is especially difficult for system calls that return a file descriptor. For predict you have to deny access to the system call but still return a valid file descriptor. To do this we change the string argument of the system call to /dev/null. This is very dangerous because we’re writing to child’s memory area.

The only use case we have for addpredict currently in Exherbo is spurious access violations. Thinking about this and after discussing in #paludis we decided that adding access violation filters is the easiest and most secure way to solve this problem. I added two magic commands to sydbox, namely addfilter and rmfilter. addfilter takes a fnmatch pattern as argument and sydbox doesn’t generate access violations for paths that match this given pattern. The access to the system call is still denied though. rmfilter also takes a pattern as argument and removes it from the list of patterns. More than one pattern can be added/removed this way.

Today I added support for this to Paludis and started changing addpredict calls with addfilter in the Exherbo repositories. I plan to kill addpredict soon.

The survey is closed.
The winner is:

Thanks everyone who voted and a lot of thanks to omp and replica!

After announcing that we need a logo, two responses came.

The first design is by David Shakaryan aka omp. The design uses spbecker’s idea which was the cover of dark side, except with some representation of a box substituted for the prism. After talking in #sydbox he decided to add a Siamese cat on top of the box making the logo even nicer.

The second design is by Sterling X. Winter aka replica. It’s a simple design featuring a Hexagram 24. Quoting from Wikipedia:

Hexagram 24 is named 復 (fù), "Returning". Other variations include "return (the
turning point)". Its inner trigram is ☳ (震 zhèn) shake = (雷) thunder, and its
outer trigram is ☷ (坤 kūn) field = (地) earth.

Of course this reminds me of the Chapter 24 song by Pink Floyd which goes like:

...
Change returns success
Going and coming without error
Action brings good fortune
...

Both of these logos are really nice and I couldn’t choose one.
I started a survey so that Exherbo users can choose which one they like best.

I’ll be very happy if you can be kind enough to participate in this survey. Thanks in advance!