Re: CVSROOT write permission vulnerability

[Mark D. Baushke]

Bibhas Kumar Samanta <address@hidden> writes:

> Hi,
> 
> I have a simple query.
> We have Solaris/unix network with NIS .
> and we use /net/<machine_name>/system/CvsRoot as our CVSROOT 
> which is accessible from all machines.
> 
> As CVSROOT requires write permission, it has 777 permission for
> all.
> But this essentially empower each user  to delete the whole
> CVSROOT , may be even mistakenly ie 
> cd /net/<machine_name>/system/CvsRoot;\rm -rf *
> 
> How can I avoid that . or do I have any mechanism to log
> who is accessing the CVSROOT area.

First, do not allow read-write NFS exporting of your repository.
This reduces access to the repository significantly.

This will mean using either pserver or rsh/ssh to connect to the
repository for commits. This only reduces your exposure as having the
ability to rsh into your server machine could still let someone go to
the directories of the repository and access files or otherwise do harm.

Note that cvs is not really a 'secure' source control system. There will
always be some wiggle room for creating problems.
 
> Or what is the common CVSROOT structure/access mechanism
> is used by you .
> 
> 
> Thanks,
> Bibhas

For myself, I believe that special-purpose machines are cheap and easy
to maintain, so I use single purpose machines as the cvs server. Users
are allowed to login via ssh for their commits and are told never to
login directly to the cvs machine. This does not stop a determined
attack against the repository. It does make is much less likely that
someone will do something accidentally.

Another method is to define SETXID_SUPPORT when building cvs. Then make
your repositories be user and group writable and your cvs executable be
set-gid on the server machine in that group. You will need to be very
careful with your commitinfo, verifyinfo, loginfo scripts about
untainting the source to avoid holes. For best results you will also
want your loginfo script to run some kind of a script to give ownership
of all of the committed files to some user other than the user running
the cvs command. A version of 'sudo' with a rule to remove any setuid
and setgid bits and change ownership to some administrative account
owner would likely do the job.

If the above looks fragile, it is. It will only stop unintentional
damage as there are windows of opportunity while the commit is occuring
to damage the files being modified by the commit.

        Good luck,
        -- Mark