The latest released version gets security fixes. While the version is 0.x, older minor versions do not.
Please do not open a public issue for a security problem.
Use GitHub's private vulnerability reporting: on the repository page choose Security, then Report a vulnerability, or go straight to https://github.com/leonkrix/netscenario/security/advisories/new. You get an answer within a few days.
The advisories that have been published are listed at https://github.com/leonkrix/netscenario/security/advisories. Please include the version, the kernel and distribution, how netscenario was started (as root or in a user namespace), and the scenario file if there is one.
netscenario creates network namespaces, virtual network devices and traffic-control rules, and it starts programs inside them. That needs privileges (CAP_NET_ADMIN in a user namespace, or root). The design rules that follow from this:
- It never touches the network of the host. All devices and rules live in namespaces that netscenario creates and removes. A rule that would apply to a host interface is refused.
- It asks for the least privilege that works. The preferred way is an unprivileged user namespace. Where that is not possible, it says what it needs and why.
- Scenario files are data, not code. A scenario cannot run commands on its own. A workload of kind
commandsays so explicitly, runs the program of itsrunlist as you (without a shell, in the namespace of its node), and that program is yours. The program is in the network namespace of its node but shares the file system, the user and the other resources of the machine with you: it can read and write what you can, and nothing limits its memory or its processes. Running a scenario file that you did not write is running its programs: read thecommandentries before you run it. docs/PROGRAMS.md says exactly what the run starts and with which variables. - It sends nothing anywhere. No telemetry, no network access of its own beyond the emulated network in the namespaces.
Reports about escaping a namespace, about a scenario file that makes the tool act outside what it was told, or about unsafe handling of the files and sockets it creates are especially welcome.