Re: source mgt. requirements solicitation

[Zack Weinberg <zack@codesourcery.com>]

I'm keeping around a lot of context.  Scroll down.

>> > > 0d. The data stored in the repository cannot be modified by
>> > >     unprivileged local users except by going through the version
>> > >     control system.  Presently I could take 'vi' to one of the ,v
>> > >     files in /cvs/gcc and break it thoroughly, or sneak something into
>> > >     the file content, and leave no trace.
>> > 
>> > There is no interaction with root, so if you own the archive, you can
>> > always do what you want.  To get anything approaching this, you have
>> > to deal with PGP signatures, SHA hashes, and the like.  OpenCM is
>> > probably the only group (including BitKeeper) that even comes close to
>> > doing this right.
>> 
>> This sort of thing has been done simply by a modified setuid (to a cvs
>> user, not root) cvs binary so users can't access the repository directly,
>> only through that binary.  More generically, with a reasonable protocol
>> for local repository access it should be possible to use GNU userv to
>> separate the repository from the users.
>
> This is a different security model.  Arch is secure because it doesn't
> depend on having priviledged access.  For example, there is an "rm
> -rf" command built into arch.
>
> I have a feeling that you are thinking of how CVS handles things, with
> a centralized server.  Part of the whole point of arch is that there
> is no centralized server.  So, for example, I can develop arch
> independently of whether Tom thinks that I am worthy enough to do so.
> I can screw up my archive as much as I want (and I have), and Tom can
> be blissfully unaware.  Easy merging is what makes this possible.
>
> So you don't, in general, have a repository that is writeable by more
> than one person.

Let me be specific about the problem I'm worried about.

As Joseph pointed out, GCC development is and will be centered around
a 'master' server.  If we wind up using a distributed system,
individual developers will take advantage of it to do offline work,
but the master repository will still act as a communication nexus
between us all, and official releases will be cut from there.  I doubt
anyone will do releases except from there.[1]  The security of this
master server is mission-critical.

The present situation, with CVS pserver enabled for read-only
anonymous access, and write privilege available via CVS-over-ssh, has
two potentially exploitable vulnerabilities that should be easy to
address in a new system.

_Imprimis_, the CVS pserver requires write privileges on the CVS
repository directories, even if it is providing only read access.
Therefore, if the 'anoncvs' user is somehow compromised -- for
instance, by a buffer overflow bug in the pserver itself -- the
attacker could potentially modify any of the ,v files stored in the
repository.  This was what I was talking about with my point 0c.  It
sounds like all the replacements for CVS have addressed this, by
allowing the anoncvs-equivalent server process to run as a user that
doesn't have OS-level write privileges on the repository.

_Secundus_, CVS-over-ssh operates by invoking 'cvs server' on the
repository host -- running under the user ID of the invoker, who must
have an account on the repository host.  It can't perform any
operations that the invoking user can't.  Which means that the
invoking user must also have OS-level write privileges on the
repository.  Now, such users are _supposed_ to be able to check in
changes to the repository, but they _aren't_ supposed to be able to
modify the ,v files with a text editor.  The distinction is crucial.
If the account of a user with write privileges is compromised, and
used to check in a malicious change, the version history is intact,
the change will be easily detected, and we can simply back out the
malice. If the account of a user with write privileges is compromised
and used to hand-edit a malicious change into a ,v file, it's quite
that this will go undetected until after half the binaries on the
planet are untrustworthy.  It is this latter scenario I would like to
be impossible.

There are several possible ways to do that.  One way is the way
Perforce does it: _all_ access, even local access, goes through p4d,
and p4d can run under its own user ID and be the only user ID with
write access to the repository.  Another way, and perhaps a cleverer
one, is OpenCM's way, where the (SHA of) the file content is the
file's identity, so a malicious change will not even be picked up.
(Please correct me if I misunderstand.)  Of course, that provides no
insulation against an attacker using a compromised account to execute
"rm -fr /path/to/repository", but *that* problem is best solved with
backups, because a disk failure could have the same effect and there's
nothing software can do about that.

zw