Visual SourceSafe - Preliminary Observations

[Joel Maslak <jmaslak () antelope net>]

Recently, I evaluated Visual SourceSafe (VSS) 6.0 for an employer.  We 
were comparing it to other network-aware source code control systems.

Visual SourceSafe is barely network aware.  By "barely", it is network 
aware in the same way an Access Database can be network aware - all 
program logic is on the client side, including access control, while the 
server contains only data (represented as files - there is no daemon or 
service on the server).

This in itself may not be a problem for some environments.

However, the installation instructions tell the administrator to create a 
share for the VSS datafiles, and to give access to "Everyone" for those 
files.  In some shops this may be acceptable, but it should not be in 
most.  At the very least, "Authenticated Users" would be a better choice.  
Even better would be to limit it to those users who actually need access.

Second, within a "project", you can not effectively control access.  While 
the user interface lets you set permissions for different files, these 
permissions are validated by the client, not the server.  Thus, anyone who 
reverse-engineers the client or, perhaps, anyone with access to the VSS 
datafiles (I'm not sure if they are encrypted; if they are, it is with a 
shared key hard-coded into the client) has access to the entire project.  
Basically, the security user interface provides a way to "advise" a client 
that he doesn't have access to a file.  The only real security is NTFS 
permissions, which, unfortunately, must apply to the entire project, not 
individual project files/directories.  To me, this is a case of "bad 
security is even worse then no security"!

My recommendations (unless someone can provide information that what I'm 
seeing is wrong):

1)  Lock down the share's permissions to only those with a "need to know"
2)  Don't bother with the security interface of VSS
3)  Put data with different security requirements in different projects
4)  Note that anyone with access to those datafiles (every developer for 
the project!) can modify version history with custom-written tools

These limitations, IMHO, makes VSS difficult to use in very large 
environments, although they probably don't affect a small development team 
much.

The version history tracking cannot be used to support audit 
functionality, as history can be changed by a knowledgeable attacker.  
There is no server enforcing the rule, "Only add new versions, keep old 
ones" - this is done by the client.  For users using the VSS client only, 
it is probably true.  But any program could in theory access these files, 
including a hacker tool which allowed for changing history (for instance, 
to slip a bug into the next version by making it look like a particular 
code file has not changed in this version; thus that piece of code is not 
reviewed by others).

For these reasons (my employer required both segregated permissions within 
projects and audit tracking), we were unable to use VSS, regardless of how 
well or poorly it actually did version tracking.  I've not seen this 
talked about elsewhere, though, so I thought I would provide my experience 
to others.  This is only a preliminary review - I'll post corrections if I 
get updated information.

-- 
Joel Maslak