CVSROOT write permission vulnerability
Hi, I have a simple query. We have Solaris/unix network with NIS . and we use /net//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//system/CvsRoot;\rm -rf * How can I avoid that . or do I have any mechanism to log who is accessing the CVSROOT area. Or what is the common CVSROOT structure/access mechanism is used by you . Thanks, Bibhas ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
Bibhas Kumar Samanta writes: > > I have a simple query. > We have Solaris/unix network with NIS . > and we use /net//system/CvsRoot as our CVSROOT > which is accessible from all machines. That means you're using NFS to access your repository. There have been lots of reports of repository corruption due to NFS interoperability bugs. If all of your machines are running Solaris you probably won't have a problem, but if they're not, you're asking for trouble. Using client/server mode with the server running on the machine that has the repository on a locally mounted disk is the preferred alternative. > 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//system/CvsRoot;\rm -rf * > > How can I avoid that . or do I have any mechanism to log > who is accessing the CVSROOT area. Setting the sticky bit (chmod -t) on a directory prevents normal users from deleting or renaming files in that directory unless they own them. -Larry Jones I don't need to improve! Everyone ELSE does! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
On Mon, Jan 20, 2003 at 10:53:38AM -0500, Larry Jones wrote: > > As CVSROOT requires write permission, it has 777 permission for > > all. > > Setting the sticky bit (chmod -t) on a directory prevents normal users > from deleting or renaming files in that directory unless they own them. Doing that in the repo would break CVS completely, wouldn't it? For most users, a commit would fail at the point where it tried to delete the old ,v file and rename the temporary copy (indeed, the sticky bit would independently block both of those operations). So only the owner of a given ,v file, and the owner of its parent directory, would be able to commit new revisions. To the original poster: Larry's main point still holds. Use client/server, not NFS. That'll also help you with the permissions problem, if you do it right. Doing it "right" has been discussed here many times; for details, try searching the list archives. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the "faceless cannonfodder" stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
Eric Siegerman writes [about setting the sticky bit]: > > Doing that in the repo would break CVS completely, wouldn't it? > For most users, a commit would fail at the point where it tried > to delete the old ,v file and rename the temporary copy (indeed, > the sticky bit would independently block both of those > operations). So only the owner of a given ,v file, and the owner > of its parent directory, would be able to commit new revisions. Yes, for directories that contain files. We've been know to use it on directories that only contain subdirectories, however. Particularly the top-level repository directory. -Larry Jones Well, it's all a question of perspective. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
On Mon, Jan 20, 2003 at 12:58:45PM -0500, Larry Jones wrote: > Eric Siegerman writes [about setting the sticky bit]: > > Doing that in the repo would break CVS completely, wouldn't it? > Yes, for directories that contain files. We've been know to use it on > directories that only contain subdirectories, however. Particularly the > top-level repository directory. Hmmm. I guess that's cheap insurance against "cd $CVSROOT; mv foo bar", but what else does it get you? Seems to me it doesn't do much about "rm -rf $CVSROOT/foo" or "rm -rf $CVSROOT"; by the time the rmdir() fails, foo's content's already toast... -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the "faceless cannonfodder" stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
Bibhas Kumar Samanta <[EMAIL PROTECTED]> writes: > Hi, > > I have a simple query. > We have Solaris/unix network with NIS . > and we use /net//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//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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
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 <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I have a simple query. > > We have Solaris/unix network with NIS . > > and we use /net//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//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 > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
> 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 > It's simpler than that: don't use NFS and the :local: access method. Just say no. I've been on CVS lists for years now, and I don't remember a single case of repository corruption that didn't involve that. Now, I rather suspect that corruption is rare anyway, but I sure wouldn't take the chance. So, you have two options, depending on the level of security you want: 1. Stop using NFS, use :pserver:. This has a very low level of security, and should be used only if you trust everybody on the network. (On the one hand, you shouldn't have developers you don't trust, on the other hand most computer fraud and vandalism is perpetrated by insiders.) 2. Stop using NFS, use :ext: with SSH. This has a high level of security, provided you disable actual logins to the machine. Remember to use an ssh agent, or the continual typing of passphrases is going to get very painful. I'm starting to wonder if removing :local: mode might not be a bad thing. It would make things more awkward on single-computer installations (at home I use it on the Linux box, and pserver on the Macs and Windows box), but it would stop people from doing something natural that turns out to be dangerous. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
I'm starting to wonder if removing :local: mode might not be a bad thing. It would make things more awkward on single-computer installations (at home I use it on the Linux box, and pserver on the Macs and Windows box), but it would stop people from doing something natural that turns out to be dangerous. I don't know how serious you are on this one but _I_ sure couldn't work without it. The only thing you could possibly imagine is to disable local mode on network mapped drives. And even then a switch to enable it nonetheless is necessary. But while working on my local drive I don't want to mess with any server stuff. bye Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
On Wed, Jan 22, 2003 at 03:55:15PM +0100, Fabian Cenedese wrote: > >I'm starting to wonder if removing :local: mode might not be a bad > >thing. That's a bit extreme, IMO. At most it could be disabled by default, with an option to enable it (either a configure option, or in CVSROOT/config, or both). Not a flat-out prohibition, but people would have to work a bit to find it. > The only thing you could possibly imagine is to > disable local mode on network mapped drives. That'd be nice. Rather a challenge to implement though -- how *does* one tell, portably and from application code, whether a given directory is locally or remotely mounted? > But while working > on my local drive I don't want to mess with any server stuff. Indeed! I might not even have any "server stuff" set up yet by the time I want to start using CVS. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the "faceless cannonfodder" stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
[ On Wednesday, January 22, 2003 at 08:37:52 (-0600), [EMAIL PROTECTED] wrote: ] > Subject: Re: CVSROOT write permission vulnerability > > I'm starting to wonder if removing :local: mode might not be a bad > thing. It would make things more awkward on single-computer > installations (at home I use it on the Linux box, and pserver on > the Macs and Windows box), but it would stop people from doing > something natural that turns out to be dangerous. "more awkward" is a vast understatement. The ":local:" mode is critical for good performance at many sites. -- Greg A. Woods +1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
