Add a sandbox enforced before options are parsed and the connection is
established to the XMPP server. This sandbox will allow network
operations.
The post-connect sandbox is unchanged and restricts operations to stdio.
The commit just adds the infrastructure for the pre-connect sandbox.
Use the UID of the xmppipe process instead of the PID in the default
name. This allows many processes running under the same user on a host
to share the same output channel and makes it easier to pre-create the
MUC if the xmppipe XMPP user does not have MUC creation privs.
Whether gethostname(2) returns an error depends on the implementation.
Some implementations:
* truncate the hostname if length is less than the hostname, with or
without a trailing NULL
* return -1 if length is less than hostname
* return -1 if length is 0
Set a default name if gethostanme() returns error.
Some errors will cause the XMPP file descriptor to be closed before
xmppipe exits. Return EBADF if close is called since the process will
terminate anyway.
When base64 encoding is enabled, ignore any messages that fail base64
decoding.
Previously signed-unsigned integer conversion would cause the return
value of b64_pton() on error (a negative integer) to be converted to a
large value. The attempt to allocate this value would force xmppipe to
exit.
Add a BPF seccomp syscall filter on Linux. Not enabled by default. To
compile:
XMPPIPE_SANDBOX=XMPPIPE_SANDBOX_SECCOMP make
The sandbox is derived from OpenSSH's seccomp sandbox by Will Drewry and
Kees Cook's tutorial on seccomp:
http://outflux.net/teach-seccomp/
The number of file descriptors enforced by setrlimit() can now be set at
compile time using a flag. The flag defaults to 0 on Linux and -1
everywhere else:
XMPPIPE_SANDBOX=XMPPIPE_SANDBOX_RLIMIT \
XMPPIPE_SANDBOX_RLIMIT_NOFILE=-1 \
make
The meaning of the XMPPIPE_SANDBOX_RLIMIT_NOFILE is:
* -1 : set rlim_cur/rlim_max to the lowest allocated file desciptor
* >=0: set rlim_cur/rlim_max to this number
On some platforms, setting rlim_cur below the value of the highest
allocated fd may interfere with polling. See commit a34d5766c5 for
details.
The rlimit sandbox disables forking processes and opening files.
The rlimit sandbox is not used by default yet. To compile it:
XMPPIPE_SANDBOX=XMPPIPE_SANDBOX_RLIMIT make
The rlimit sandbox should work on any platform. However the interaction
of RLIMIT_NOFILE with poll(2) (and select(2)?) on some platforms (FreeBSD
but really any OS besides Linux) is problematic:
* opening a number of fd's, setting RLIMIT_NOFILE to 0, calling
poll(2) on the fdset
Linux: works
FreeBSD: fails
* opening a number of fd's, setting RLIMIT_NOFILE to maxfd+1, calling
poll(2) on the fdset
Linux: works
FreeBSD: works
The issue with the second option is that a library may have opened a
sequence of file descriptors then closed the lower numbered fd's:
open() => 3
open() => 4
open() => 5
close(3)
close(4)
maxfd = 5
RLIMIT_NOFILE would be set to 6 (stdin, stdout, stderr, 3, 4, 5) and the
sandbox would allow re-opening fd's 3 and 4.
One possible fix would be to run through the sequence of fd's before
entering the rlimit sandbox:
* test if the fd is closed
* if the fd is closed, dup2(STDIN_FILENO, fd)
Since the closed fd's are not part of the pollset, they will not be
polled and should be ignored.
Note we can't simply move maxfd to the lowest unused fd because
libstrophe maintains the fd number as internal, opaque state.
Empirically, the xmpp fd is always 3. Another option would be to abort
the process if the fd does not equal 3.
Prepare for sandboxing the xmppipe process by adding a function called
after all file descriptors are allocated.
The intent of the sandbox is to limit the xmppipe process to the role
of a component in a shell pipeline: reading from stdin, reading/writing
to the XMPP socket and writing to stdout. Any activity not involved with
using stdio should force the process to exit.
The sandbox function will vary based on the capabilities of the
platform. The default sandbox function does nothing.
Limitations of the sandbox:
Probably the biggest risk is in session establishment:
* the TLS handshake
* the XML parsing
The sandbox is enforced after the TLS connection is established, i.e.,
after the file descriptor for the XMPP session is allocated and so has no
effect on the TLS handshake or the initial XMPP handshake.
Possibly an initial sandbox could be setup for the connection phase
followed by a stricter sandbox for the stdio phase.
