PDA

Bekijk Volledige Versie : Visual SourceSafe - Preliminary Observations



Joel Maslak
31/12/02, 06:13
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