Hi all (more skipable spam/details on VMs and security),
In our view a VM is not much different from user jobs. Currently on the Grid we have no idea what a user is in fact calculating, when they call their "bank-encryption cracker" for example "cancer-research". User generated stuff is always very hard to trace, especially when they are trying to hide their traces... The first thing that clever hackers do is install a root kit, turn of all logging (or better yet filter illegal stuff out, so it seems ok) and encrypt everything else...
So what we minimally need to prevent is for example illegal access to data (scientist want to share, but certain data needs to be protected from other groups than their peers), so in case of user submitted VMs, that means strict network security. And prevent illegal access from and to the Internet (a cluster of VMs could form a perfect botnet).
which means the logs have a very high level of trust.
This is a bit naive, we do not trust machines that we do not maintain ourselves, ever (and we certainly do not think that our own work is always trustworthy). Or rather, we trust outside VMs just as much as other user generated jobs, which is not very much... With that said, in case of problems we can freeze a VM and inspect it manually with forensic tools like sleuthkit, this works for many OSses and is easier with VMs than with a physical host. And on the physical host we can monitor the syslogs etc to see if the VM tries to break out of its assigned space. On the network we do traffic and possibly packet inspection, port scans etc. The level of needed security depends on the requested usage by the user. We stack VLANS on VLANs, and on each compute node, the physical interface supports a virtual bridge, which connects to virtual interface of the VM. So separation between VLANS is both done on the physical bridges as on virtual bridges.
More details on our security policies you need to discuss with our security officers ;-)
Regards,
Floris
-----Original Message----- From: Mischa Salle [mailto:msalle@nikhef.nl] Sent: woensdag 28 april 2010 14:21 To: Floris Sluiter Cc: 'Sander Klous'; ct-grid@nikhef.nl Subject: Re: [Ct-grid] Fwd: Updated draft of VM policy
On Mon, Apr 26, 2010 at 02:24:27PM +0200, Floris Sluiter wrote:
...Sounds good to me. What about performance issues? I'm especially concerned about file I/O and network I/O.
Any virtualization has overhead. The best you can squeeze it is about 90-95% percent on I/O and close to 100% native for CPU. This is independent from the network topology and with which rights a VM is running: i.e. how your network topology is designed does not make any difference on how your virtualization performs compared to the same setup for a native solution.
Hi Floris,
just a short question with respect to the network topology. Could you give some details on how you would do this. In order to get performance you need to put your VMs on a bridge, so can you get sufficient security or even a closed off VLAN with ebtables?
Furthermore, concerning the difference, or as you say equality, between a class-3 and a class-2 VM, how do you see this concerning for example syslogging? With a standard WN all logging is done by root in a site-installed WN, which means the logs have a very high level of trust. With a class-2 VM, logging is done by root inside the VM in a way endorsed by the endorser. With a class-3 VM there is no such thing, even if you demand logging to syslog (no idea how to do that with Windows), it's completely untrusted. Maybe you see this differently? The point is, even if the VM has only local user rights, just as a normal grid job, it's not clear to me how you can keep track of what that normal job is doing in the case of a VM. If a normal grid job does strange things, you can see traces in your syslog, in the VM case, you only see the VM process such as kvm, which is much harder to trace.
Cheers, Mischa