Export (0) Print
Expand All
Debugging: Root Out Elusive Production Bugs with These Effective Techniques
Smart Tags: Simplify UI Development with Custom Designer Actions in Visual Studio
Ten Essential Tools: Visual Studio Add-Ins Every Developer Should Download Now
XML Comments: Document Your Code in No Time At All with Macros in Visual Studio
Expand Minimize

Introduction to Visual SourceSafe Database Security

Visual Studio .NET 2003
 

Christine Woskett and Oded Ye Shekel
Visual SourceSafe Team
Microsoft Corporation

January 2003

Summary: This article identifies security issues that administrators need to address when creating and managing Visual SourceSafe 6.0 and earlier databases.

This is a two-part article. For step-by-step instructions for securing a Visual SourceSafe database, see How to: Lock Down a Visual SourceSafe Database. (5 printed pages)

Contents

Introduction
Terminology
Securing the Database and Managing the Users
Guidelines for Securing Your Database
Additional Considerations

Introduction

This information is for any Visual SourceSafe (VSS) user who creates a VSS database, grants other users permissions to access a file share containing a database, or otherwise manages user rights and assignments in the VSS Administrator program.

Terminology

Security is the process of controlling access to resources, based on Windows user credentials and permissions.

Permissions are rules associated with a local resource or a resource shared on a network, such as a file, directory, or printer; permissions can be granted to groups, global groups, and even individual Windows users. When you grant Windows permissions, you specify the level of access for groups and users.

Operating system or file system security checks the permissions each time that a Windows user interacts with the shared resource to determine whether that user has the necessary permissions. For example, if that user is attempting to save a file in a folder, that user must have Write permissions for that folder.

Sharing makes Windows resources, such as folders and printers, available to others. Shared resource permissions restrict a shared resource's availability over the network to only certain Windows users. The administrator of a shared folder grants permissions to Windows users to enable remote access to the folder and subfolders. Sharing of Windows resources is different from sharing files and projects in VSS.

Rights in VSS specify which VSS users have access to a specific VSS project. There are four levels of user access rights in VSS: read, check out/check in, add/rename/delete, and destroy. The default level for new users of the database can be specified.

Assignments in VSS specify which VSS projects a specified VSS user has access to.

VSS database folder is the Windows folder that contains the Srcsafe.ini file for the database and other VSS folders such as Data and Users.

Securing the Database and Managing the Users

The VSS Administrator program provides tools for managing your VSS users by specifying access rights for individual users or individual VSS projects in the VSS database. To truly secure your database, however, you must use Windows integrated security to restrict access to the VSS folders by setting sharing and security permissions for those folders. As shown in the following diagram, your shared VSS database is only as secure as the shared network folder in which it is located. Follow the database lockdown procedures to strengthen the Windows security by setting or changing sharing permissions for the database folder when you create a database or add or delete VSS users. Otherwise, a malicious user on the network can easily circumvent the transparent wall of VSS user Rights and Assignments. Do not rely on VSS to secure your data: even read-only VSS users can delete a VSS database from a shared network folder to which they have access.

Visual SourceSafe Security Architecture

The VSS user Rights and Assignments that you set in the VSS Administrator program are independent of Windows sharing permissions for the VSS database folder. The VSS user name and password are used by VSS for user management and accessing VSS. The VSS user name is used to manage users' rights and assignments in the VSS Administrator program and it identifies the user at logon, in history information, and in files reports. Users can log on to VSS using the user name and password. VSS creates and keeps track of an initialization file, Ss.ini, for each VSS user that contains settings to customize that user's VSS environment. To protect that initialization file, follow the instructions in How to: Lock Down a Visual SourceSafe Database.

For more information about Windows security, access control, and permissions, see the Windows Help.

Guidelines for Securing Your Database

To secure your database, you must use Windows integrated security to restrict access to the VSS folders so that only authorized Windows users can access the database or run the VSS Administrator program. The security of your VSS database is determined by the security of the folder that contains it. To implement the security described here for your VSS database, the database must be installed on an NT file system (NTFS), which is available on Windows NT 4.0, Windows 2000, Windows XP, and later. When a VSS database is installed on an NTFS volume, you can grant permissions for individual files and folders; the file allocation table (FAT) file system applies the same permissions to an entire share.

Restrict Share Permissions

When you create a shared database, it is strongly recommended that you use Windows Explorer to restrict sharing permissions for the VSS folders. You must remove the Everyone group that is added automatically when you share the VSS database folder. You can create two groups of Windows users – VSS administrators and VSS users – and grant each group appropriate permissions for the VSS database folder and the other VSS folders. Each VSS user must also be granted Read and Write permissions for the Users/username folder that corresponds to that user's VSS user name. For instructions, see How to: Lock Down a Visual SourceSafe Database.

Manage Users

When you add or delete VSS users, you must not only use the user list in the VSS Administrator program to manage those users, but also add or remove their Windows share permissions. For instructions, see How to: Lock Down a Visual SourceSafe Database.

Additional Considerations

Install the Database in a Secure Location

During installation of VSS, a database is created by default in the VSS Data folder, which is under Program Files. That database is intended for personal use only and should not be shared. Use the database in the default location only if you are required to by other programs.

Any Windows user who has Full Control permissions for the VSS folders can replace the executable files in the Win32 folder: follow the procedures in How to: Lock Down a Visual SourceSafe Database to grant Full Control permissions to only those in the VSS Administrator group. Also, all VSS database users require permissions for the VSS database folder, and if that folder is under the Program Files folder, it contains executable files and related resources.

Do not create a shared database in your system folders or in your Documents and Settings folders.

Hide the VSS Data Share

You can hide the network share so that it is very difficult for remote Windows users to determine whether a server has a share and whether VSS is installed. The network share does not appear when a Windows user browses the server. To hide the network share, add $ to the end of the folder name, for example, instead of \\server\vssdb1 use \\server\vssdb1$. You will have to tell your VSS users the exact location of the database so that they can add the database to the list of Available databases in the Open SourceSafe Database dialog box.

Shadow Folders

If you create a shadow folder for a VSS project, the Windows user permissions for the VSS folders are not inherited by the shadow folder. Grant Read and Write permissions for the shadow folder to all VSS users, and grant only Read permissions to any Windows users who require read-only access to the shadow folder. For details, see Create Shadow Folders.

It is recommended that you create a shadow folder on a different share from the VSS database so that Windows users with read-only access to the shadow folder do not have any access permissions for the share that contains the database. It is also recommended that you create a shadow folder for a specific VSS project, not for the root project $, so that Windows users who have access to the shadow folder have access to only that VSS project and not to your entire database.

Note   When you delete a file or project from a VSS project, that file or project is not deleted from the shadow folder.

Journal File

If you create a journal file, it is recommended that you secure that file by locating it in the same folder as the Srcsafe.ini file and granting Windows Read and Write permissions for the journal file to VSS users.

Permissions Required to Install and Run VSS

You must be a Windows Administrator for the computer to install VSS, but Administrator permissions are not required to run either the VSS Administrator program or VSS Explorer and the command line.

The Admin and Guest User Names

When you create a VSS database, two user names are created by default: Admin and Guest. The passwords for the Admin user and the Guest user are blank. It is recommended that you set a password for the Admin user by using the Change Password command in the VSS Administrator program. You can either delete the Guest user or set a password for the Guest user by using the Change Password command in the VSS Administrator program. For details, see Change a User Password.

Passwords

If your VSS users must type a user name and password to log on to VSS, tell them not to use the same password for the operating system and for VSS. If the passwords are the same, and a hacker finds the VSS password, the hacker can use the user's identity to access the operating system and all programs.

SSUSER and SSPWD Environment Variables

You can set the SSUSER and SSPWD environment variables on your computer to your VSS user name and password so that you avoid the logon prompt each time you enter a VSS command at the command line or start VSS Explorer.

If you set those environment variables, any user of your computer might be able to read those variables and run VSS using your user name and password.

Using the Network Name for Automatic User Logon

Visual SourceSafe provides a Use network name for automatic user log in option that can be used to allow Visual SourceSafe integration with Microsoft Visual InterDev, Visual Studio .Net, and FrontPage. For information about the security considerations when using this option, see the Microsoft Knowledge Base article Q283618.

Use of VSS Project Rights

If you want to specify access for individual VSS users or individual VSS projects, use the Rights by Project and Rights Assignments for Users commands on the Tools menu in the VSS Administrator program. In Visual SourceSafe version 6.0c and earlier, you can activate the menu commands by selecting Enable Project Security on the Project Security tab in the SourceSafe Options dialog box. In later versions of Visual SourceSafe, you can activate the menu commands by selecting Enable Rights and Assignments commands on the Project Rights tab in the SourceSafe Options dialog box.

Audit User Activity

Using the VSS Administrator program, you can create a journal file, which is a text file that records any action by a VSS user that generates a history entry for a file or project in the VSS database. For details, see General Options Tab (Tools Menu) or Journal_File Initialization Variable. Windows Administrators can audit many security-related events, for example, access to particular files and folders. Monitoring such security-related events can help a VSS Administrator to detect attempts to compromise the data in a VSS database. For information about auditing security events and auditing access to objects such as files and folders, see the Windows Help.

See Also

How to: Lock Down a Visual SourceSafe Database

Show:
© 2014 Microsoft