Ask Slashdot: Safe Learning Environment For VMs? 212
First time accepted submitter rarkian writes "I am the teacher in this story. I teach Python and C++ to high school students: grades 9-12. I use CentOS 6 with DRBL to run my computer lab. Some of my students have become Linux experts. Next year I'm planning on allowing students to create and run their own VMs in a segregated LAN. Any advice on which virtualization technology to use and security concerns with allowing students to be root in a VM?"
Re:Safety? (Score:2, Interesting)
Unless they take down the network, e.g. running a rogue DHCP server. Or they use it to hack other systems on the network, e.g. password-sniffing the other student's credentials when they log in from their VMs.
VM is irrelevant (Score:5, Interesting)
The fact that your using VM's is largely moot and goes back to the line of thought that VM's are somehow not 'real' computers. VM's run the same operating systems, software, have the same bugs, vulnerabilities and everything else as a physical computer. You need to patch them just like any other computer and you need to license them just like a regular computer. The fact that they are VM's really only makes two differences practical differences that matter, fist is that is easy to roll them back and second is that your aren't running on bare metal.
In other words you have a core issue that needs addressed of giving students root access to a computer. In an isolated environment this isn't necessarily a bad thing. Understand that they exploit root and see what they can do with it, however they are there to learn and if you can do so safely and without disruption of what your trying to teach then let them. Your focus needs to be on making it safe for those around them and that means making sure your VLAN and any related Internet access are properly setup. The lab is a lab and as long as you can make sure they aren't getting access to anyone persons computer than let them have at it.
A good rule of thumb is to roll your sessions back prior to the start of every single class. This always gives a fresh machine and the students will quickly learn how to set their VM just the way they want it.
SELinux on the host (Score:4, Interesting)
APT-Cacher, Squid (Score:4, Interesting)
They can start each class with a fresh snapshot. In effect they would be restoring from backups. The configuration files from some other networked storage or their thumb drives and the applications themselves from the repositories. I've done something similar, but on bare metal, and after about half a dozen times they don't notice -- it had become such second nature to install and restore applications. Heck you might even have them practice installing the whole system from scratch. If you go that route, they can become quite proficient with installation and resource allocation. PXE booting a netinstall image helps there.
However, once you start to load packages from the net things can really slow down unless you prepare. The best way is to have a cache like APT-Cacher or Squid on your LAN or host system and have them configure their systems to use it for APT. For the cache to be most effective, you have to pre-load it before each class. That's easy and can be done while doing other things. It only takes time not attention. But once you have the cache loaded, installation will fly and can be done in 15 - 20 minutes. After that they weren't shy about installing on their own computers at home or helping their friends.
It depends on what you're trying to protect (Score:4, Interesting)
So far, I see lots of advice about VM breakouts and network isolation. If this were a production datacenter where uptime was a criteria, this is all well and good. I suspect that this isn't what you need to hear, however.
I see three things you could be attempting to protect:
1) The larger school network.
2) The VM host infrastructure.
3) The VMs themselves.
1) A student on a VM is no more dangerous to the network than one who can connect to the school wireless with a laptop or smartphone. If the lab uplinks to the same network as the broader access, your risk profile is unchanged.
2) Make sure the VMs can't route to the host and keep it patched. If a student managed to break out of a VM in a patched hosting environment, do some forensics and find the bug then sell it. It's probably worth more than you make in a year. Seriously, if they can do this, they deserve to win. You might as well worry about protecting against nation-state sponsored attacks.
3) Make sure that the class work is backed up (a git server, perhaps) and then don't worry about it. Seriously, just throw the VMs away after each class (or every night, etc) and start with a clean one the next time they log in. Don't spend time trying to outsmart a classroom full of bored highschoolers. Instead, make it so it doesn't matter when they break something.
Re:Safety? (Score:4, Interesting)
Unless they take down the network, e.g. running a rogue DHCP server. Or they use it to hack other systems on the network, e.g. password-sniffing the other student's credentials when they log in from their VMs.
So... nothing they couldn't do much easier/more safely by just pulling the network cable out of the physical machine and connecting it to their netbook?
Re:Set up VLANs (Score:5, Interesting)
> This is Linux were talking about. What could you possibly teach them without an internet
> connection? The only use I see is teaching shell scripting or something, since other tasks like
> package management, and sane server configuration kinda require an active internet connection.
Well Python, that is what he said he wanted to teach them :)
Beyond that, you are right, I say, the key is not security but recovery. Template boxes so that a new VM can be spun up effortlessly, then let them have at it. Segment the lab off from the rest of the network, maybe let the lab out to the internet, but not to the schools internal network.
However the key is, you can always blow away a machine and reimage it to get class moving, so there is no real danger in letting them play. Hell, I took a class that taught us administration and hacking eachother's machines was explicitly allowed, as long as it stayed in the lab. (we were also required to create a guest account as one of the exercises)
Gives the advanced kids who are bored with the class something to do that lets them learn too; I certanly had fun.
Re:Set up VLANs (Score:4, Interesting)
As you pointed out below, VLANs in general are trustworthy when properly configured with a proper switch. I did nothing but netsec work in the late 90s, and everything was airgapped; we'd never have frames from two networks on the same wire. If you wanted to cross security zones, it was at L3 on a firewall and to different wires and switches.
On the other hand, it seemed like back then a new practical way to defeat VLANs was coming out every other week, so this was a wise precaution.
That said, keep in mind that VMware also affords some additional security in terms of VLANs. Physical switches have to connect to virtual switches to interact with the VMware layers (either the hypervisor for control traffic, or with the VMs for VM traffic), and the hypervisor itself will enforce a lot of things. On a VMware vSwitch properly configured:
- VMs can't enter promiscuous mode, change their MAC address, or forge transmits with the wrong L2 address
- QinQ frames are discarded
- The hypervisor itself will determine which virtual nics on a vswitch should receive copies of a frame, depending on which VLAN tag is on a portgroup
- Guests can't send tagged frames if their portgroup is set with a VLAN; you have to specifically configure a trunk on a portgroup to pass VLAN tags in and out of the guest environment
If the network was homogeneously ESX nodes and administratively controlled network equipment, you could likely enforce security between VMs with VLANs even with a dumb hub.
Obviously, airgapping and single-role wires will create better security than VLANs, because there always remains a chance that an undiscovered bug will allow breaching that L2 barrier, but that's true for everything.
Re:Set up VLANs (Score:4, Interesting)
Umm, no. Not unless your switch is defective, or massively misconfigured. VLANs are very secure, when done properly. And the same security measures needed to protect VLANs are the same ones you need to protect switching in general (see CAM overflows, arp spoofing, and such).
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml [cisco.com]
If you leave your trunk/native VLAN at 1, you're in trouble. If you configure user-facing ports as auto-negotiate, or trunk without explicitly specifying allowed VLANs, you're in trouble.