0515adceaa
To reach (at least) a conceptually equivalent security level as implemented by --enable-sandbox in slirp4netns, we need to create a new mount namespace and pivot_root() into a new (empty) mountpoint, so that passt and pasta can't access any filesystem resource after initialisation. While at it, also detach IPC, PID (only for passt, to prevent vulnerabilities based on the knowledge of a target PID), and UTS namespaces. With this approach, if we apply the seccomp filters right after the configuration step, the number of allowed syscalls grows further. To prevent this, defer the application of seccomp policies after the initialisation phase, before the main loop, that's where we expect bad things to happen, potentially. This way, we get back to 22 allowed syscalls for passt and 34 for pasta, on x86_64. While at it, move #syscalls notes to specific code paths wherever it conceptually makes sense. We have to open all the file handles we'll ever need before sandboxing: - the packet capture file can only be opened once, drop instance numbers from the default path and use the (pre-sandbox) PID instead - /proc/net/tcp{,v6} and /proc/net/udp{,v6}, for automatic detection of bound ports in pasta mode, are now opened only once, before sandboxing, and their handles are stored in the execution context - the UNIX domain socket for passt is also bound only once, before sandboxing: to reject clients after the first one, instead of closing the listening socket, keep it open, accept and immediately discard new connection if we already have a valid one Clarify the (unchanged) behaviour for --netns-only in the man page. To actually make passt and pasta processes run in a separate PID namespace, we need to unshare(CLONE_NEWPID) before forking to background (if configured to do so). Introduce a small daemon() implementation, __daemon(), that additionally saves the PID file before forking. While running in foreground, the process itself can't move to a new PID namespace (a process can't change the notion of its own PID): mention that in the man page. For some reason, fork() in a detached PID namespace causes SIGTERM and SIGQUIT to be ignored, even if the handler is still reported as SIG_DFL: add a signal handler that just exits. We can now drop most of the pasta_child_handler() implementation, that took care of terminating all processes running in the same namespace, if pasta started a shell: the shell itself is now the init process in that namespace, and all children will terminate once the init process exits. Issuing 'echo $$' in a detached PID namespace won't return the actual namespace PID as seen from the init namespace: adapt demo and test setup scripts to reflect that. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> |
||
---|---|---|
.. | ||
build | ||
demo | ||
dhcp | ||
distro | ||
env | ||
icmp | ||
lib | ||
ndp | ||
perf | ||
tcp | ||
two_guests | ||
udp | ||
ci | ||
README.md | ||
run | ||
run_demo |
Scope
This directory contains test cases for passt and pasta and a simple POSIX shell-based framework to define them, and run them as a suite.
These tests can be run as part of a continuous integration workflow, and are also used to provide short usage demos, with video recording, for passt and pasta basic use cases.
Run
Dependencies
Packages
The tests require some package dependencies commonly available in Linux distributions. If some packages are not available, the test groups that need them will be selectively skipped.
This is a non-exhaustive list of packages that might not commonly be installed on a system, i.e. common utilities such as a shell are not included here.
Example for Debian, and possibly most Debian-based distributions:
build-essential git jq strace iperf3 qemu-system-x86 tmux sipcalc bc
clang-tidy cppcheck isc-dhcp-common udhcpc psmisc linux-cpupower
netcat-openbsd fakeroot lz4 lm-sensors qemu-system-arm qemu-system-ppc
qemu-system-misc qemu-system-x86`
Other tools
Test measuring request-response and connect-request-response latencies use
neper
, which is not commonly packaged by distributions and needs to be built
and installed manually:
git clone https://github.com/google/neper
cd neper; make
cp tcp_crr tcp_rr udp_rr /usr/local/bin
Virtual machine images are built during test executions using mbuto, the shell script is sourced via git as needed, so there's no need to actually install it.
Special requirements for continuous integration and demo modes
Running the test suite as continuous integration or demo modes will record a video of the steps being executed, and create binary packages. The demo mode uses cool-retro-term as terminal, whereas the continuous integration mode uses MATE Terminal by default.
The following additional packages are commonly needed as well:
dbus-x11 xdotool x11-utils xvfb ffmpeg mate-terminal cool-retro-term xauth
dconf-cli alien linux-perf tshark sqlite3`
For convenience, suitable profiles for MATE Terminal and cool-retro-term are
provided under the env
directory. To source them:
dconf load /org/mate/terminal/profiles/ < env/mate-terminal.profile
cp env/cool_retro_term.sqlite ~/.local/share/cool-retro-term/QML/OfflineStorage/Databases/*.sqlite
Regular test
Just issue:
./run
from the test
directory. Elevated privileges are not needed.
Continuous integration
Issuing:
./ci
will run the whole test suite while recording a video of the execution, and it will also build JavaScript fragments used on http://passt.top/ for performance data tables and links to specific video offsets.
Demo mode
Issuing:
./demo
will run the demo cases under demo
, recording videos as well.
Framework
The implementation of the testing framework is under lib
, and it provides
facilities for terminal and tmux session management, interpretation of test
directives, video recording, and suchlike. Test cases are organised in the
remaining directories.
Test cases can be implemented as POSIX shell scripts, or as a set of directives,
which are not formally documented here, but should be clear enough from the
existing cases. The entry point for interpretation of test directives is
implemented in lib/test
.