Re: CVSROOT write permission vulnerability

[Bibhas Kumar Samanta]

Thanks to Mark, Eric and Larry.

SO just to summarize, seems I have two options,

1.stop nfs method of sharing , use :pserver

2. Evenif nfs is used, i need to setid the repository
  and cvs

Bibhas

"Mark D. Baushke" wrote:
> 
> 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
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs