Security

Changing the VMware Server 2.0 default permissions

I have been using VMware Server 2.0 (beta 2) on both Windows and Linux platforms for a while now. For Windows systems that are a member of an Active Directory domain, there are inherited permissions that may be assigned from Group Policy. If you want to change that, here are a couple of pointers in changing the security model.

To start looking at the permissions of the server installation, click the server on the left side of the browser view and then click the permissions tab at the top. The default permission is the local Administrators of the Windows system will be in the VMware Server Administrators role as shown below:

Before you make any modifications to the security model, add your desired configuration. That way, you can protect yourself from orphaning your administrative access to the server. Click the New Permission link in the command section, and add the user from either the local accounts of the Windows system or a user from the Active Directory domain or security group from the domain. The figure below shows the addition of the RWVVMwareAdmins group to the role of Administrator within the VMware Server 2.0 web interface:

Once that is added, the new configuration should be tested to ensure the proper access is available. Once the new access is verified, it would be safe to then remove the previous default access (if needed). If you get stuck, you can save off the .VMDK files and reinstall the product if needed.

While the web interface for VMware Server 2.0 takes some getting used to when compared to the thick client for versions 1.0x, features continue to be added to the free virtualization product that can be suited to test and development or live environments.

VMware security coming to the forefront?

Many virtualization analysts punt on the issue of security. But two recent events have brought security into higher relief: the uncovering of VMware’s file-sharing security flaw and VMware’s announcement of VMsafe, a virtual appliance that adds a layer of security to apps running on virtual machines. While VMsafe attempts to address VMware’s file-sharing problems, the flaw has raised questions about VMware security and the security of virtualization technologies in general.

In a recent SearchSecurity.com article, one interviewee said that after testing virtualization, he determined that putting virtualization into production would require reworking tried-and-true centralized security controls. Another interviewee expressed concerns about future problems, particularly a breach involving the hypervisor.

But we aren’t the only ones asking questions about security for virtual environments. At Rational Suvivability, author Christopher Hoff takes a different angle:

Virtualization up until now has quietly marked a tipping point where we see the disruption stretch security architectures and technologies to their breaking point and in many cases make much of our invested security portfolio redundant and irrelevant.

Has virtualization brought a whole new set of security requirements? Has your company explored or purchased virtualization-specific security software? Share your security-in-virtual-environments experience, and we’ll send you a $10 Starbucks gift card. Email me at hdrake@techtarget.com.