RE: CVS Security Issues
[ On Friday, December 19, 2003 at 11:18:57 (-0500), Jim.Hyslop wrote: ] Subject: RE: CVS Security Issues Why is this level of security so important? Exactly what are the security attacks you're concerned with? Exactly the kind which necessesitated this recent strong(security update)/strong release. Well, clearly pserver is not secure because the password is sent effectively in plain text, allowing anyone with a packet sniffer to retrieve CVS passwords. That's a big no-no on the security level. But this is well-documented in the Cederqvist - as I recall, it says something along the lines of if you want real security, don't use pserver. Meanwhile people the world over continut to mis-use pserver. It's been proven time and time again that we can't stomp out ignorance about digital security by documentation alone. However we can remove features that are 100,000% guaranteed insecure and force people to either think a little more to gain the insecurity they desire, or at maybe at least to get them to follow the herd over to using some more secure digital security mechanism that's widely available and easy to use. So, where am I deluding myself? If you have any use whatsoever for something like CVS then clearly you _must_ also have some need for at least minimal security, whether you realize it or not. There's no point to recording revision information if anybody can muck with it and there is no accountability whatsoever amongst your users. I.e. if you use pserver for anything more than totally anonymous access then you really have no security, none, zip, zilch, zero, nada, not one bit of security whatsoever. If you don't see the conflict here then clearly you are deluding yourself! ;-) I.e. please do not pretend you can gain anything by pretending to make the CVSROOT/passwd file harder to mess with. That's a good point - as Bruce Schneier, author of Applied Cryptography and a computer security expert, is fond of saying: Security is only as good as its weakest link. For pserver, access to the passwd file is not the weakest link by any means. Moving the file to a different location will not significantly improve its inherent insecurity. Worse. It will cause people to have an increased level of _false_ security. BTW, for this discussion Schneier's book Serets Lies: Digital Security in a Networked World is much more apropos. :-) -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS Security Issues
[ On Friday, December 19, 2003 at 18:04:42 (+0100), Walter, Jan wrote: ] Subject: RE: CVS Security Issues The only reason to put the passwords somewhere else is to prevent someone from accidentally checking it out and accidentally changing or deleting someone elses' password and checking the file back in. It's a support issue, not a security one, whether the user intended to change their password or someone elses' is another question entirely. But I think there is a 'gain' here by keeping the passwd file somewhere else where some git can't wipe all the users by accident and bring development to a grinding halt. Sorry, but it _is_ a security issue. If accidents can cause problems with data used for authentication or authorisation then the causes of those accidents are security issues. Furthermore since this only gives a false sense of security, the whole idea of making the change is a major security issue in and of itself. On security, you have two types of security anyways: 1) protection against malicious people and 2) protection for your data from accidental damage, deletion, or whatever (protecting users from themselves). CVS is part of category 2, obviously with the support of backup systems and so on. Of course. Pserver figures into category 2 because you prevent the users from accidentally working in the actual repository and doing stuff like deleting directories. Nope. Pserver bypasses both types of security, even if the proposed changes are made. Pserver is _negative_ security, by its very definition. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS security audit?
[ On Friday, December 19, 2003 at 21:00:46 (-0500), Larry Jones wrote: ] Subject: Re: CVS security audit? The objection is that CVS was never *designed*, or even *intended*, to be secure. An audit will affect my confidence not one whit -- it's sufficient to keep honest people honest, nothing more. Indeed. I couldn't agree more. Furthermore CVS was designed to use any sufficiently transparent remote job execution protocol that could have a wrapper put around it such that it works like rsh. What more could anyone ask for than to leave both communications _and_ security to some other specialized tools? -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Unediting a commited file
All: I have an issue of unediting a file that has been committed to the repository from the workspace. I tried to execute the following command: cvs unedit Training in CVS.xls But it didn't put the file in unedit mode. It stcuk in edit. I ran update, and queried the file, but to no avail. The reason I want to put it in an Unedit mode is to place a lock on the file. And, so long the file is in edit mode it is not allowing me to lock the file? The environment: Client server vonfiguration with pserver authontication mode. I habve CVS 1.10 version on my server. --- Greg A. Woods [EMAIL PROTECTED] wrote: [ On Friday, December 19, 2003 at 11:18:57 (-0500), Jim.Hyslop wrote: ] Subject: RE: CVS Security Issues Why is this level of security so important? Exactly what are the security attacks you're concerned with? Exactly the kind which necessesitated this recent strong(security update)/strong release. Well, clearly pserver is not secure because the password is sent effectively in plain text, allowing anyone with a packet sniffer to retrieve CVS passwords. That's a big no-no on the security level. But this is well-documented in the Cederqvist - as I recall, it says something along the lines of if you want real security, don't use pserver. Meanwhile people the world over continut to mis-use pserver. It's been proven time and time again that we can't stomp out ignorance about digital security by documentation alone. However we can remove features that are 100,000% guaranteed insecure and force people to either think a little more to gain the insecurity they desire, or at maybe at least to get them to follow the herd over to using some more secure digital security mechanism that's widely available and easy to use. So, where am I deluding myself? If you have any use whatsoever for something like CVS then clearly you _must_ also have some need for at least minimal security, whether you realize it or not. There's no point to recording revision information if anybody can muck with it and there is no accountability whatsoever amongst your users. I.e. if you use pserver for anything more than totally anonymous access then you really have no security, none, zip, zilch, zero, nada, not one bit of security whatsoever. If you don't see the conflict here then clearly you are deluding yourself! ;-) I.e. please do not pretend you can gain anything by pretending to make the CVSROOT/passwd file harder to mess with. That's a good point - as Bruce Schneier, author of Applied Cryptography and a computer security expert, is fond of saying: Security is only as good as its weakest link. For pserver, access to the passwd file is not the weakest link by any means. Moving the file to a different location will not significantly improve its inherent insecurity. Worse. It will cause people to have an increased level of _false_ security. BTW, for this discussion Schneier's book Serets Lies: Digital Security in a Networked World is much more apropos. :-) -- Greg A. Woods +1 416 218-0098 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
An RPM of cvs-1.11.11-1 for i386...
can be found here: http://cougaar.org/project/showfiles.php?group_id=7 Thanks again for the helpful instructions last week. Yours, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Checksum failure: serious problem or not?
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote: [on eliminating 'P' status code] Eric Siegerman writes: Hmm, what would it take to convince you? :-) A whole bunch of people to agree (vociferously) with you. I hope there was a missing smiley, Larry. The problem is that most people who get confused by this issue probably don't subscribe to this list. Heck, most of them probably aren't even aware this list exists. So I don't think you'll hear all the grumbling and confusion that the two messages generate. For user interface issues like this, you need to stop thinking as a CVS developer, and put yourself in the mindset of the average CVS user. Sure, to you the distinction between 'P' and 'U' is important, and to me as a CVS administrator the distinction is of at least academic interest - but to most users, all that's important is the final result. As Eric has said, exactly *how* the file gets updated is an implementation detail. Most users do not need - or want - to know how it happens, they just want it to happen, and to know if there's a problem. I would submit that the majority of CVS users fall into this category - and they most likely will not be subscribed to this list, or to the bug-cvs list. If someone were to submit a patch that substituted 'U' for 'P' unless a particular flag was set, would you at least consider committing that patch? [on checksum failure messages] Feel free to submit patches. The tricky part is that it's the *client* that detects the problem. The client doesn't have sufficient information to do a merge (merges happen on the server), and there is no client in local mode to do the detecting. Well, even in local mode the client must have some knowledge of how to do a merge, otherwise it could never merge a modified file. Could the following sequence work: - CVS renames the original file to a .# file name - CVS applies the patch to the original file - If the checksum on the file succeeds, delete the .# file - Otherwise, delete the patched file, rename the .# file back to its original name, somehow force the file's state to 'Modified' (brute force way would be to 'touch' the file) and restart the operation as a normal update on a modified file. I haven't examined the code, so I don't know how easily that sequence would fit in with the existing code. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com/) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS Pserver with multiple repositories?
I have implemented a CVS Pserver in a Red
Hat Machine to serve to 3 projects. I installed CVS 1.12.5 on a RED HAT 9
Machine. To make the service RUNI edited cvspserver arquive in
/etc/xinetd.d... It looks like this...
service cvspserver
{
port = 2401
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/bin/cvs
server_args = -f
--allow-root=/cvs/rep/casnav pserver
}
I edited config to System-auth=Yes so I
connect remote with a system user of the server. I installed the "cvspermissions
0.3" Scriptsand it let me set permissions on the modules with some
commands...
But the 3 projects are hosted in a Singe
repository! So... all people in the 3 projects can see all files in all
projects... cvspermissions can only manage tag and commit permissions per
modules to restricted users... but the read rights are managed by
repository.
I could set the permissions by filesystem
access ... but I dont know if its the best way. Im new in the Linux world... so
I every post in this list affraid of being dumb!
I think to in create others files under
/etc/xinetd.d and run a repository in each port... but it not seems right for
me.
What I like to do is... multiple
repositories, That I can manage with cvspermissions and access with pserver. It
wold be Must! If someone helpme to take the best or right way... I
thanks.
I thanks you!
Sorry about, I promess I will have english
classes next year.
Diego. Rio de Janeiro.
Brazil.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Stable CVS Version 1.11.11 Released! strong(security update)/strong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Geoff Beier wrote: On Fri, Dec 19, 2003 at 04:36:44PM -0500, Derek Robert Price wrote: Actually, They've made it easier than that. After you set up your ~/.rpmmacros file, and assuming that you don't want to edit your spec file, just type: rpmbuild -ta cvs-1.12.5.tar.bz2 I can't believe I missed that one before :-) The man page just mentions it almost in passing, but it's certainly there in the synopsis... Do you know offhand what rules the -t switch uses to select a spec file to use? Not a clue. I do know that if you pass it cvs-1.11.11.tar.bz2, it will unpack the tarball and find cvs-1.11.11/cvs.spec, so I would assume it looks for top/package.spec, but I don't know if it can find anything else. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- Do not walk behind me, for I may not lead. Do not walk ahead of me, for I may not follow. Do not walk beside me, either. Just leave me alone. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/5xt2LD1OTBfyMaQRAr/rAJ46ai8GSN14HHyravDwITIJEMg1VgCdGrJk qH4qG0vgLmR/KzigebeoHYc= =tu9F -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS Pserver with multiple repositories?
Title: Message
Hi!
What
you require is to define the server args string as:
server_args
= -f --allow-root=/cvs/rep/casnav --allow-root=/cvs/repo/proj2 --allow-root=/cvs/repo/proj2
pserver
And also create the required repositories for all the three projects.
Also, you will have to create separate groups.
The same can be done with your current setup also, but then the top level
repository will have to have permission for all groups or rather anybody to
access it. Thus, taking security in consideration, you need to have three
different repositories with the permissions only for users of the group for whom
that repository is meant for. You can thus set the permissions to 2770 for these
three directories and put the directories with the username of the Project
Leader or the Project Manager, so that only he can access the CVSROOT module for
administrative purposes.
Hope this helps.
Gagneet
PS: Your English is good so don't worry about it..
:-))
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Diego
Ribeiro de AndradeSent: Monday, 22 December, 2003 21:08
PMTo: INFO CVSSubject: CVS Pserver with multiple
repositories?
I have implemented a CVS Pserver in a Red
Hat Machine to serve to 3 projects. I installed CVS 1.12.5 on a RED HAT 9
Machine. To make the service RUNI edited cvspserver arquive in
/etc/xinetd.d... It looks like this...
service cvspserver
{
port = 2401
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/bin/cvs
server_args = -f
--allow-root=/cvs/rep/casnav pserver
}
I edited config to System-auth=Yes so I
connect remote with a system user of the server. I installed the
"cvspermissions 0.3" Scriptsand it let me set permissions on the modules
with some commands...
But the 3 projects are hosted in a Singe
repository! So... all people in the 3 projects can see all files in all
projects... cvspermissions can only manage tag and commit permissions per
modules to restricted users... but the read rights are managed by
repository.
I could set the permissions by filesystem
access ... but I dont know if its the best way. Im new in the Linux world...
so I every post in this list affraid of being dumb!
I think to in create others files under
/etc/xinetd.d and run a repository in each port... but it not seems right for
me.
What I like to do is... multiple
repositories, That I can manage with cvspermissions and access with pserver.
It wold be Must! If someone helpme to take the best or right way... I
thanks.
I thanks you!
Sorry about, I promess I will have
english classes next year.
Diego. Rio de Janeiro.
Brazil.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checksum failure: serious problem or not?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim.Hyslop [EMAIL PROTECTED] writes: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote: [on eliminating 'P' status code] Eric Siegerman writes: Hmm, what would it take to convince you? :-) A whole bunch of people to agree (vociferously) with you. I hope there was a missing smiley, Larry. The problem is that most people who get confused by this issue probably don't subscribe to this list. Heck, most of them probably aren't even aware this list exists. So I don't think you'll hear all the grumbling and confusion that the two messages generate. For user interface issues like this, you need to stop thinking as a CVS developer, and put yourself in the mindset of the average CVS user. Sure, to you the distinction between 'P' and 'U' is important, and to me as a CVS administrator the distinction is of at least academic interest - but to most users, all that's important is the final result. As Eric has said, exactly *how* the file gets updated is an implementation detail. Most users do not need - or want - to know how it happens, they just want it to happen, and to know if there's a problem. I would submit that the majority of CVS users fall into this category - and they most likely will not be subscribed to this list, or to the bug-cvs list. The distinction betwne U and P can be useful over a wan... there may be other uses as well from an audit point of view as to how folks are (ab)using their checked out trees. However, there is probably insufficient distinction to make that very useful. If someone were to submit a patch that substituted 'U' for 'P' unless a particular flag was set, would you at least consider committing that patch? Yes. [on checksum failure messages] Feel free to submit patches. The tricky part is that it's the *client* that detects the problem. The client doesn't have sufficient information to do a merge (merges happen on the server), and there is no client in local mode to do the detecting. Well, even in local mode the client must have some knowledge of how to do a merge, otherwise it could never merge a modified file. In theory, the server had a copy of the client file to do the patch in the first place and the client copy either became stale or was corrupted while the server copy was being used to generate a patch. Could the following sequence work: - CVS renames the original file to a .# file name - CVS applies the patch to the original file - If the checksum on the file succeeds, delete the .# file - Otherwise, delete the patched file, rename the .# file back to its original name, somehow force the file's state to 'Modified' (brute force way would be to 'touch' the file) and restart the operation as a normal update on a modified file. Hmmm... that will be very tricky... I haven't examined the code, so I don't know how easily that sequence would fit in with the existing code. Look at the code. If you have a patch to suggest, it would be interesting to see it. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/59Zc3x41pRYZE/gRAuA8AKDkWB9cw/DQlytU4d4rPTVGGMRamgCgzAqR XUVypPGeZGq/NNYBQAMhSIU= =zRtS -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Info-cvs Digest, Vol 13, Issue 31
I will be on vacation from 12/23/03 through 01/05/06. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checksum failure: serious problem or not?
Jim.Hyslop writes: I hope there was a missing smiley, Larry. The problem is that most people who get confused by this issue probably don't subscribe to this list. Heck, most of them probably aren't even aware this list exists. So I don't think you'll hear all the grumbling and confusion that the two messages generate. What confusion? A novice user isn't going to know what *any* of the codes mean without consulting the manual, which explains both codes. Experienced users have presumably been seeing P for quite some time and know what it means. About the only possible confusion is for long time local mode users that switch to client/server mode and start seeing a code they haven't seen before. Hopefully, they'll consult the manual rather than asking here or falling into a state of permanent confusion. If someone were to submit a patch that substituted 'U' for 'P' unless a particular flag was set, would you at least consider committing that patch? Not me, although someone else might. Absent a groundswell of dissenting opinion, this just isn't an important enough issue to spend any time on. (If someone actually wants to pursue this, however, please don't add a flag, just get rid of P completely.) Well, even in local mode the client must have some knowledge of how to do a merge, otherwise it could never merge a modified file. The server does the merge, not the client. In local mode, you're essentially using the server directly (without a client). -Larry Jones I don't think math is a science, I think it's a religion. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
