Security: accessing any file on the server - via qemu

[candlerb]

This is probably of academic interest only, but I will point out that anyone with access to the GNS3 web interface or API can access any file readable to the gns3 user on the host system via qemu (not in the same way as #1894). Here's how:

• Create a new project
• Add an Ubuntu-20.04-Cloud appliance node (and connect it to a NAT if you like)
• Go into the node settings, Advanced, "Additional settings"
• Change to: -nographic -drive file=/etc/sysctl.conf,if=virtio,index=1,media=disk,id=drive1,readonly
• Start the VM
• Get a console on the VM (the appliance provides login: "ubuntu", "ubuntu")
• sudo cat /dev/vdb

You have just read the file /etc/sysctl.conf from the host.

Implications (today)

Unrestricted access to qemu lets it be used as a proxy to the filesystem.

• Under the current architecture, this means it's absolutely critical that gns3 runs as a non-root user.
• Advise users to configure their system as if it were a multi-user host, and treat anyone who accesses the gns3 API or web interface the same as if they'd just ssh'd into the system. Use filesystem permissions to ensure that the gns3 user has no access to anything sensitive. Apply authentication and HTTPS to gns3 web/API connections. If all this is done, it is no worse than shell accounts on a multi-user system (but still more exposure than you'd normally expect from running a "web application")
• Sandboxing:
  • Run gns3 on a dedicated server - expensive
  • Run gns3 inside a dedicated VM - requires nested kvm, which isn't very efficient
  • Run gns3 inside a chroot - but it needs to be quite fat, with python runtime, qemu, ubridge etc
  • Run gns3 inside a docker container (e.g. using docker, podman or k8s). This is probably the most practical solution and works well. Note that /dev/kvm and /dev/net/tun need to be passed through, in a way which is compatible with unprivileged containers (smarter-device-manager can do this for k8s)

It might be possible to sanitise the qemu "additional settings", either within GNS3 itself, or in a wrapper which calls qemu. However I don't want to see "additional settings" disabled entirely; I find it far too useful (e.g. to set -cpu Skylake-Client, which is benign). An option in gns3.conf to give a validation regexp for qemu additional settings could be a good idea, but there might be other ways to abuse qemu that I haven't thought of, so it might not actually gain any security.

Implications (future ideas)

• Running each individual qemu process inside its own container would be even better. This would likely complicate how they communicate with each other, as well as being a major change to how gns3 spawns qemu processes.
• Perhaps gns3 could manage dynamic apparmor profiles for qemu - libvirt already has this ability - but that sounds like a lot of work. A static apparmor profile, which limits qemu access to images_path and projects_path only - may be reasonably straightforward though.

[grossmj]

Thanks for bridging this to our attention, definitely something we should try to mitigate as much as we can :+1:

[candlerb]

In https://github.com/GNS3/gns3-server/issues/1921#issuecomment-867435063 you said:

Regarding getting images via our API, this won't be possible in the future thanks to our new RBAC implementation in version 3.0.

I think that RBAC could help a lot with this issue too. For example, normal users (students) could be restricted to using pre-defined appliances; only superusers could change the qemu settings on a node. This could also avoid some DoS attacks, such as creating qemu nodes that use vast amounts of RAM.