Re: Linux security issues as they pertain to CVS
Greg A. Woods wrote: The problem is that I see it as if you're trying to say that CVS Pserver plus SSL equals secure. It most certainly does not. You have no provable authentication and thus no provable accountability. Not on the server side, but it prevents sniffing. Server certificate checking can prove to the client that it got the correct server and this can prevent the user from sending her password to an imposter. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- My father often told me, We have servants and machines in order that our will may be carried out beyond the reach of our own arms. Machines are more powerful than servants and more obedient and less rebellious, but machines have no judgement and will not remonstrate with us when our will is foolish, and will not disobey us when our will is evil. In times and places where people despise the gods, those most in need of servants have machines, or choose servants who will behave like machines. I believe this will continue until the gods stop laughing. -Orson Scott Card, Children of the Mind ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Linux security issues as they pertain to CVS
[Greg Woods wrote...] By allowing *anyone* to use CVS on your machine you are very nearly granting them shell access anyway! If you do so in a totally unaccountable way (i.e. with pserver) then you've just lost the integrity (and thus the security) of your repository. I.e. CVS cannot guarantee that it will not allow a remote user to execute any arbitrary command (and indeed maybe even any arbitrary code whatsoever). There is no inherent security in CVS -- anyone who can execute it can probably do anything as the user it executes as. Perhaps this is what I am missing, then. How does CVS access very nearly grant them shell access? By what mechanism do you see this happening? Are you assuming that there is a risk worthy of consideration that, since no service can be proven to not possess program bugs, and since some bugs allow code to be injected into programs, any running service must be assumed to contain code that was not a part of its original design, code contributed by a hacker at runtime that may run in any account to which the service has access? The implication of this would be that no restriction in the design of a program is of any significance to security, since no assumptions can be made about the actual contents of the running code. The only factor about a running server that is of any significance is the set of accounts to which it is may acquire access during execution. Of course, this would apply to the code implementing tunneling services or ssh or any of a dozen other services as well, no? The fundamental paradox of security is that you have to trust someone in order to know whom to trust. :-) If we aren't worried about those services, then the argument is really I trust these coders not to screw up (perhaps only because I have to) but not those coders. That's fine; but if that is the substance of your argument, it needs to be stated plainly. Or is there something more specific to CVS that I am missing? Let us presume from the outset that reasonable precautions have been made about the CVSROOT directory that prevent it from being modified except in a local account on the system. This is a known vulnerability, dealt with easily enough. Is there something else in CVS that permits its users to affect files outside of the repository? Once we're past this point in the discussion, I'll bring up the notion of what is or isn't considered acceptable risk and why. Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Linux security issues as they pertain to CVS
Greg A. Woods wrote: [ On Tuesday, May 29, 2001 at 09:18:33 (-0500), Thornley, David wrote: ] Subject: RE: Linux security issues as they pertain to CVS Any problems with running pserver over an encrypted channel? It seems to met that would be just as secure as ssh access (and, of course, just as unsafe - the biggest potential security problems being the guys on both ends of the channel). That more or less defeats the purpose since you usually have to have a real identity to establish a secure channel connection to a server in the first place so why not just use that channel for remote job execution? (unless you're talking about an IPsec VPN tunnel, but then you've got different issues to worry about) No you don't. A secure channel only need authenticate the server, possibly using an external certificate authority, a la HTTPS. CVS pserver on the other hand is under the full and direct control of the (or rather *any*) user at the other end so you cannot transfer your trust to the client CVS program and you cannot be sure that the person at the remote keyboard really is the same joe -- there's no secure link between the authentication done by the remote client computer to allow that user to access it and whatever might be claimed over the pserver channel. Therefore pserver even over a secure channel is not itself secure. Which is perfectly fine and possibly even desirable when you, as CVS administrator, have no control over the client machine anyhow. If I have root access on the client I could use any login I wished anyhow. In other words, you'd rather know I knew the password you gave me. In this case the secure channel should protect you from password sniffers. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Cynic: Someone who smells the flowers and looks for the casket ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Linux security issues as they pertain to CVS
[ On Wednesday, May 30, 2001 at 09:23:20 (-0400), Derek R. Price wrote: ] Subject: Re: Linux security issues as they pertain to CVS No you don't. A secure channel only need authenticate the server, possibly using an external certificate authority, a la HTTPS. You cannot have a secure channel without some form of authentication. HTTPS alone does not give you a secure channel. It might give you a secret channel, but unless you know an awful lot more about certificates and SSL than the average person then you do not have any clue as to even who's machine is on the other end. Even worse it doesn't tell the server which *user* is responsible for opening the channel. That's why I suggested using rsh over an IPsec VPN tunnel. You could do the same over an SSH tunnel. The assumptions of who you have to trust are more or less the same. Which is perfectly fine and possibly even desirable when you, as CVS administrator, have no control over the client machine anyhow. If I have root access on the client I could use any login I wished anyhow. In other words, you'd rather know I knew the password you gave me. In this case the secure channel should protect you from password sniffers. I think you're focusing on some (admittedly important) details without looking at the whole picture. You cannot have security if you don't cover *all* of your bases equally! You also must understand the inherent limitations and assumptions built into your client and server platforms so that you can establish a true trust path that'll make it possible for you to hold your users accountable for their actions. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [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: Linux security issues as they pertain to CVS
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 7:48 PM To: Mark Cc: CVS Mailing List Subject: Re: Linux security issues as they pertain to CVS The problem is that pserver cannot be made secure. Literally cannot. It runs on a raw, insecure TCP circuit and is subject to all kinds of man-in-the-middle attacks, connection hijacking, spoofing, etc. Any problems with running pserver over an encrypted channel? It seems to met that would be just as secure as ssh access (and, of course, just as unsafe - the biggest potential security problems being the guys on both ends of the channel). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Linux security issues as they pertain to CVS
Mark wrote: I think a good explaination of how to run pserver as a non-root user would be good to have in the CVS manual. Like Larry said, as long as all the CVS users in CVSROOT/passwd map to the same user that the CVS binary is running as, things should work. Documentation patches happily accepted. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Five days is not too long to wait for a gun. Five days is not too long to wait for a gun. Five days is not too long to wait for a gun... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Linux security issues as they pertain to CVS
Thornley, David wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 7:48 PM To: Mark Cc: CVS Mailing List Subject: Re: Linux security issues as they pertain to CVS The problem is that pserver cannot be made secure. Literally cannot. It runs on a raw, insecure TCP circuit and is subject to all kinds of man-in-the-middle attacks, connection hijacking, spoofing, etc. Any problems with running pserver over an encrypted channel? It seems to met that would be just as secure as ssh access (and, of course, just as unsafe - the biggest potential security problems being the guys on both ends of the channel). It depends on the encrypted channel implementation and SSH configuration... SSH, I know, can be configured to change the encryption keys once an hour and the like. I expect some of the channel encryptors are capable of similar but I don't know the details. Of course, SSH _could_ be granting shell access to users which is a separate security issue. And with both SSH and pserver, the security of the user's local file system is a limitation since if the ~/.cvspass or the ~/.ssh/* secret keys are compromised then so is your system. SSH does allow a password to encrypt the secret key but there may be no way to guarantee that your users are using that feature and it's possible that using that feature in a useful manner is a challenge for some users. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I predict future happiness for Americans if they can prevent the government from wasting the labors of the people under the pretense of taking care of them. - Thomas Jefferson ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Linux security issues as they pertain to CVS
Greg A. Woods wrote: [ On Saturday, May 26, 2001 at 03:07:20 (-0400), Larry Jones wrote: ] Subject: Re: Linux security issues as they pertain to CVS Greg A. Woods writes: So, if you don't have root access then how the heck do you propose to implement CVS Pserver?!?!?!? (Hint: you cannot.) Of course you can. All you need to do is run a private copy of inetd (or whatever replacement you like) as a non-root user, have it run CVS as the same non-root user, and use CVSROOT/passwd to map all valid CVS users to that same non-root system user. QED. Yeah, and there's nc -l too. But is either going to work in a production environment in a development shop? I doubt it Why not? I'll bet it'll bring any sane and knowledgeable security officer down so hard on your head too that you won't even know what hit you. Why? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- 170. If you try to fail, and succeed, which have you done? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Linux security issues as they pertain to CVS
[ On Tuesday, May 29, 2001 at 09:18:33 (-0500), Thornley, David wrote: ] Subject: RE: Linux security issues as they pertain to CVS Any problems with running pserver over an encrypted channel? It seems to met that would be just as secure as ssh access (and, of course, just as unsafe - the biggest potential security problems being the guys on both ends of the channel). That more or less defeats the purpose since you usually have to have a real identity to establish a secure channel connection to a server in the first place so why not just use that channel for remote job execution? (unless you're talking about an IPsec VPN tunnel, but then you've got different issues to worry about) With something like SSH the server host must implicitly trust the client host (which is why it has to establish the identity of the client host), and the user must implicitly trust both his client and the server -- i.e. every bit of hardware and software between the tips of his fingers and the magnetic domains on the surface of the server's disks. The trick is that the owner of the hardware, and the other bits on the same disk(s) has to trust the user too, and that's where things get fun. If you've got an end-to-end IPsec tunnel between the CVS server and the CVS client machine(s) then as a CVS administrator you are probably literally better off to use rsh and to transfer your trust to the client computer (i.e. assume that when it says the user joe calling then it is indeed the same user joe you would have authorise access to if you had authenticated him, and that the remote client has itself authenticated the person at the keyboard and determined him to be joe) since in many ways you've implicitly done that already by accepting the IPsec tunnelled packets in the first place CVS pserver on the other hand is under the full and direct control of the (or rather *any*) user at the other end so you cannot transfer your trust to the client CVS program and you cannot be sure that the person at the remote keyboard really is the same joe -- there's no secure link between the authentication done by the remote client computer to allow that user to access it and whatever might be claimed over the pserver channel. Therefore pserver even over a secure channel is not itself secure. Proper use and understanding of SSH teaches administrators where they've really placed their trust. They would be wise to learn from it. This is even more critially important when the remote client is itself running on an insecure platform. If you cannot trust that client system to run SSH then you most certainly cannot trust it with anything else. (and that's where intrusion detection becomes important, eg. why employees are often required to wear photo-ID badges in larger organisations) Encryption alone does not give you security. Security has four tightly coupled parts: Authentication, Authorisation, Integrity, Privacy; and you cannot call something secure if you take away one of those components or if you mis-use any one in such a way that you've disconnected it from the others. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [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: Linux security issues as they pertain to CVS
[ On Tuesday, May 29, 2001 at 13:59:09 (-0400), Derek R. Price wrote: ] Subject: Re: Linux security issues as they pertain to CVS Yeah, and there's nc -l too. But is either going to work in a production environment in a development shop? I doubt it Why not? One problem is that as a sysadmin if I saw ined-derek running on my machine I'd kill it first and ask questions later I'll bet it'll bring any sane and knowledgeable security officer down so hard on your head too that you won't even know what hit you. Why? First off you're offering a new network service, and even if it's only on the internal network you'd better bet the security guys want to know what it's all about. Secondly once they find out what you're actually running they'll be all over you to accept full responsibilty for everything in your repository as if you wrote it yourself (since you have no proof that you didn't and you don't even have any proof of who might have). -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [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: Linux security issues as they pertain to CVS
Greg A. Woods writes: So, if you don't have root access then how the heck do you propose to implement CVS Pserver?!?!?!? (Hint: you cannot.) Of course you can. All you need to do is run a private copy of inetd (or whatever replacement you like) as a non-root user, have it run CVS as the same non-root user, and use CVSROOT/passwd to map all valid CVS users to that same non-root system user. QED. -Larry Jones What a stupid world. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Linux security issues as they pertain to CVS
[ On Saturday, May 26, 2001 at 03:07:20 (-0400), Larry Jones wrote: ] Subject: Re: Linux security issues as they pertain to CVS Greg A. Woods writes: So, if you don't have root access then how the heck do you propose to implement CVS Pserver?!?!?!? (Hint: you cannot.) Of course you can. All you need to do is run a private copy of inetd (or whatever replacement you like) as a non-root user, have it run CVS as the same non-root user, and use CVSROOT/passwd to map all valid CVS users to that same non-root system user. QED. Yeah, and there's nc -l too. But is either going to work in a production environment in a development shop? I doubt it I'll bet it'll bring any sane and knowledgeable security officer down so hard on your head too that you won't even know what hit you. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [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: Linux security issues as they pertain to CVS
Ralph Mack writes: Now it seems to me that when looking at a program I have to ask What actions can this program perform in a setuid() environment? The problem is that that question is generally unanswerable. CVS is a big program that, if you follow the general advice for setting up pserver, runs as root. The intent is that it only runs as root long enough to authenticate the user and then uses setuid() to run as the user for the rest of the time so that all of the actions that you expect it to perform will be performed as the user. However, it is extremely difficult to prove that it isn't possible to trick it into doing something unexpected while it's running as root, and there are lots of known ways to trick it into running code as someone else, even root. The most obvious of those is to add or modify a $CVSROOT/CVSROOT/passwd that maps a user with a known password to another user, but there are lots of more subtle ways, too. That said, I agree with your main point that one has to determine the appropriate level of risk. When running on a mostly-trusted, reasonably secure intranet, pserver is no more risky than rsh, and probably a lot easier to set up than ssh. -Larry Jones I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Linux security issues as they pertain to CVS
[ On Friday, May 25, 2001 at 10:50:43 (-0400), Larry Jones wrote: ] Subject: Re: Linux security issues as they pertain to CVS The problem is that that question is generally unanswerable. CVS is a big program that, if you follow the general advice for setting up pserver, runs as root. The intent is that it only runs as root long enough to authenticate the user and then uses setuid() to run as the user for the rest of the time so that all of the actions that you expect it to perform will be performed as the user. However, it is extremely difficult to prove that it isn't possible to trick it into doing something unexpected while it's running as root, and there are lots of known ways to trick it into running code as someone else, even root. It is impossible to prove mathematically that such a trick cannot be performed, at least on any normal unix implementation. Indeed it is possible on many many systems to trick a formerly privileged process to return to its privileged status, even if that program tried to be careful to permanently throw away its privileges. This means any buffer overflow or printf-format bug that tricks the process into running code that was not originally part of its binary image can make CVS run as root again, and of course from there it's trivial to own the whole system (chroot or none, even). Some of the systems that allow this are buggy. Others are broken by design (the system will not let a process permanently discharge its privileged state). I have made changes to my NetBSD kernel which I believe prevent this from ever happening (at the expense of totally eliminating the ill-designed system calls which allow it in the first place), but even with those changes I would still not feel safe enough to run CVS as root from inetd (i.e. as a non-anonymous pserver). Writing privilged code in Unix is very incredibly difficult to do correctly (writing privileged code that gets its privileges from being a setuid binary is of course even harder, but not by a whole lot). CVS is turned into privileged code if you start it as root from inetd, whether it wants to be or not. CVS was not written anywhere nearly that carefully, never mind with an eye to being run as root. Indeed if you build it normally and try to start it from the command line as root it will rightfully refuse to run! Combining this latter fact with the privilege re-enhancing problems and you're a sitting duck if you run CVS pserver as root. Worst of all of course is the fact that CVS does not need pserver junk. It works entirely perfectly with any external remote job execution tool. In that form it is devoid of all responsibilities w.r.t. authentication, authorisation, integrity and privacy. The CVS administrator is free to choose any external RJE tool that meets their security requirements in combination with the needs of their clients (eg. rsh, ssh, stunnel, a VPN+rsh, etc.). Let the security tools do their job and let them take responsibility for *all* security issues! -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [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: Linux security issues as they pertain to CVS
[ On Friday, May 25, 2001 at 14:51:41 (-0700), Mark wrote: ] Subject: Re: Linux security issues as they pertain to CVS I think CVS does need the pserver junk. I may not always be everyones first choice, but it needs to be there and maintained. The CVS Administrator does not always have root access, thus may not always be able to implement whatever sercurity measures he sees fit. So, if you don't have root access then how the heck do you propose to implement CVS Pserver?!?!?!? (Hint: you cannot.) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [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: Linux security issues as they pertain to CVS
[ On Friday, May 25, 2001 at 14:38:07 (-0700), Mike Castle wrote: ] Subject: Re: Linux security issues as they pertain to CVS On Fri, May 25, 2001 at 04:21:08PM -0400, Greg A. Woods wrote: Worst of all of course is the fact that CVS does not need pserver junk. What would you propose as a suitable tools for anonymous cvs access. An anonymous SSH account, of course. Pretty easy to set up, even. However if you wanted something simpler (less heavy-weight), and you don't care about the security and integrity of the client TCP connection, then it's pretty easy to set up something like rsh, invoked from inetd, that does no authentication at all (and which of course you'd run as some unprivileged user, perhaps in a chroot area with a statically linked CVS binary through the help of a very tiny and secure chroot'ing wrapper). The simplest implementation would be a little shell script using nc (aka netcat) on the client, with inetd on the server side. I've not set this up for CVS, but I've done it time and time again for other similar tools. Works every time, though provides litterally no security whatsoever (unless maybe you have TCP Wrappers integrated into your inetd, as many do these days). -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [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: Linux security issues as they pertain to CVS
[ On Friday, May 25, 2001 at 14:51:41 (-0700), Mark wrote: ] Subject: Re: Linux security issues as they pertain to CVS It is a large company and a lot of red tape to get anything done. I've had all of 45 minutes with the System admin about getting CVS setup since I started. He would prefer not running CVS running as root, and if root has to run it they would have to own CVS, test it and create a whole new line of red tape for changes/updates/patches. I don't see the problem. CVS via SSH never runs as root. Just use it! I have seen people mention pserver can be run from a non-root used, after hours I searching the archives, that web site was the only real description on how to do it. It's trivial (though I don't know if the code has been broken to make it not actually work in practice)! Just don't use root in the user field in the /etc/inetd.conf entry for pserver! You have to have root privileges to set it up, of course. I think pserver should be improved on to reach a reasonalble secure level or operations (I've leave that to those more experienced in security that I). The problem is that pserver cannot be made secure. Literally cannot. It runs on a raw, insecure TCP circuit and is subject to all kinds of man-in-the-middle attacks, connection hijacking, spoofing, etc. If you don't want huge amounts of security then use rsh instead of ssh. However if, as in your case, your security officer won't allow .rhosts then you need to consider that perhaps you *do* need something semi-secure and as such your very best choice is SSH (because it already works and there's a vast body of experience with it). I think a good explaination of how to run pserver as a non-root user would be good to have in the CVS manual. Me too! I think psever (as root or non-root) may be fine for most companies, running behind a firewall and not servicing clients from the internet. Maybe. Most security problems lie on the inside of the firewall though. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [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
