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
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/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 [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/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 [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
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
CVSROOT write permission vulnerability
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. 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
