UMLazi Guests are locked in tightly controlled chroot()ed jails to prevent attackers who take control of a Guest from getting much access to the host system. Here are some of the considerations that went into the design of the jail.
* Directory permissions
It’s a lot more difficult to bust out of a jail and/or attack a machine from a jail if you don’t have the ability to write files (such as exploit scripts) to the jail. By locking down the permissions of the directories in the jail, and setting the ownerships to root, Guest users aren’t able to write files into the jail.
In a couple of places, user write permissions are unavoidable because the UML kernel _must_ write to the directory. These are /tmp (where the UML kernel mmaps its RAM file) and /control (where the UML kernel stores its PID file and mconsole socket) . We mitigate the risk by limiting the size of the files and number of inodes the user is allowed to create to the bare minimum needed to run a Guest. We also mount these directories with “noexec” and “nosuid”, to make things especially difficult.
* UBD devices
A root user inside a Guest might overwrite the beginning of a ubd device with a malicious program, then, chmod it executable, and coerce the UML kernel into executing it. The best defense we can offer here is preventing the Guest from being able to chmod the UBD device. Since a user can’t chmod a file they don’t own, we set the ownership of the UBD devices to “root”, and give the UML user write permissions through group ownership.
* Kernel permissions
The UML kernel in the jail is owned by root and not writable by the user.
Okay, if I’m pointing out the strengths of the jail, I also need to point out the weaknesses. /dev/net/tun is probably the biggest weaknessl. This device needs to exist in the jail and be writable by the Guest user for networking to function. Unfortunately, any user with write permissions on this device can create as many tun devices as they want on the host, named pretty much whatever they want. I don’t think this can be used to compromise the Host (though it is a window into kernelspace), but it could be used as a DoS.
The tuntap driver _does_ understand users, and has the ability to limit access to tun interfaces to certain users. I’m thinking this could be solved by a patch that limits tun interface creation to root. Any other ideas?