Re: Linux security issues as they pertain to CVS
[ On Friday, June 1, 2001 at 14:02:22 (-0400), Derek R. Price wrote: ] > Subject: 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. Why bother? You're gaining so little and adding yet more opportunities for fatally wrong perceptions to creep in. I.e. if something's worth doing then it's worth doing right (the first time!). > 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. Have you implemented that? Securely (i.e. with real Unix IDs)? Why not just use SSH? It can do that already, out-of-the-box even! -- 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" 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
[ On Thursday, May 31, 2001 at 08:06:35 (-0400), Derek R. Price wrote: ] > Subject: Re: Linux security issues as they pertain to CVS > > I don't agree. There are different levels of security, and I will grant that some > are simply deterrents, but costs are going to be weighed in any security > implementation decision. I'm not talking about "levels of security" (indeed all security is simply a matter of paying enough (in whatever currency is necessary) for deterrents to reduce the risk of a successful exploit down to an acceptable level). There is no such thing as "absolute security" and that's not what I was trying to imply. 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. The problem with even allowing pserver to continue to exist (with or without SSL) in its present form (i.e. within CVS) is that it plainly misleads administrators not trained in understanding trust into having the wrong impression about the level of security they have actually implemented if they choose to use it. This is plainly visible every day in questions put to this list. -- 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" wrote: > 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. I don't agree. There are different levels of security, and I will grant that some are simply deterrents, but costs are going to be weighed in any security implementation decision. My data is not all that valuable to a thief so any security compromises on my system will likely amount to vandalism which can be fixed with a small amount of downtime, CVS change backouts, and maybe access to tape backups. The analogy would be to putting locks on the door to my apartment vs. barred windows. There is a whole different class of people who might walk into my place if they found the door unlocked vs. those who are actually willing to break a window to get in. Since I know I live in a fairly nice neighborhood, I'm not going to bar the window since I prefer the unmarred view. Besides, when I lock myself out I can still break the window myself. :) Not barring the windows above the ground floor could extend this analogy - the windows are still more secure for most purposes than unbarred windows on the first floor, but the costs of using them are higher since I must ascend at least one flight of steps to get there. To go even further, I'm not so paranoid or important enough to want to paint over the windows and lose the view to protect myself against snipers... Just an example, but I wanted to make the point that there are trade-offs in any security decision (as with most other real-world decisions), which is why flexibility is my priority here. I'm not trying to fight any efforts to make CVS more secure, and far from it I would accept or at least evaluate most patches in this direction, but I wish to keep a range of security options from simple to use but insecure to tightly secure and harder to use. Until someone designs a perfectly secure but still usable system, which I don't hesitate to say won't ever happen, the system administrator should be allowed to configure the system to meet her needs. I'm not attempting to force anybody to use pserver, just providing what I believe are the facts involved in these particular trade-offs. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- 155. I had a life once... now I have a computer and a modem. ___ 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
"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 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
[ 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
"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
"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
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
> -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
[ 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
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
Greg, > 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). This is interesting and you obviously have a lot of experience in this area - can you elaborate either here or via private eMail? What system calls? What design flaws? Is Linux one of the systems to which you refer? I want to understand the mechanism well enough to avoid problems in coding wherever possible and to identify and correct problems in other folks' code that I encounter. Forewarned is forearmed. > 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. And any external remote job execution tool will also presumably be using setuid() to ensure that it follows the rules because that is how any daemon does it, right? Its chief advantage is that rje tools tend to be more closely examined because the cost (and benefit, I suppose, to some) of a hole in such a tool is proportionally higher. However, I am beginning to understand Mr. Price's argument... It occurs to me that :pserver brings one valuable thing to the table that other mechanisms do not. It recognizes that there are two kinds of CVS user identity - the user identity through which source changes as tracked by CVS, and the operating system user account used to determine permissions. In other modes of access, the operating system user identity becomes the sole user identity tracked by CVS, since there is no other identity to be found. This "identity of identities" :-) is a problem for many environments. System administrators want exclusive control of system user account creation. They don't want to deal with user accounts for individual CVS users - CVS users come and go at an alarming rate especially on open source projects - the road to Linux was paved with good intentions - and system administrators aren't equipped to deal with user account management at faster than the typical corporate hire/fire rate. They would rather delegate CVS user identity management to someone closely associated with the repository they are serving, someone who can't create user accounts or groups, only assign CVS users to existing user accounts. CVS users under the same system account have the same access to the same files and belong to the same groups. However, CVS is open source and can change. An access mode that uses something external and well-examined to secure the connection and verify account access safely (or better yet provides hooks to do so) but separately manages and secures the user identity within CVS would be of great value. It could even continue to use the familiar CVSROOT/passwd file for the latter role. Now is that what Mr. Price did or did he do something else? Ralph ___ 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
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 > > 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
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. I am a month into a job to set up a CM program with CVS. We currently don't have CVS running yet. Here's the situation: 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 want to be able to admin CVS as far removed from dependancy on the Sys Admins as possible. I don't want to submit requests for new users, wait on Sys Admins to test any patches to CVS I might want to try out, create repositories as needed, control access to repositories (unix groups), add new users, switch users about projects, etc... I want to be free from the 15 levels of approvals and signoffs and 1 to 4 week turnaround times well you get the picture. As for the network environment, .rhosts are not allowed, 80-90% of the developers do NOT have UNIX logins. They are not running any ecryption stuff, just plain NIS+. The company network is behind a firewall and there is a level of trust, as with any company, to give developers write access to the code. I have read lots of posts from the archives about security and CVS client/server, and what I got from them is that it would be great if developers just didn't need write access, then things would be alot better. But we have to step out from that and accept some risk so we may develop code and be a profitable company. That said. Now what is the least dependant way (minimal dependancy on sysadms and other support groups) and easiest on the developers to role out a client/server CVS solution behind a coporate firewall, developers do not have/want UNIX logins? I am going to try a jailed root wrapper that setuid to a non-root user (no passwd/no shell if possible) and setgid to the group that owns the repository, in order to run CVS without root. This will reduce the dependancy of the Sysadms to disk space and the wrapper program. I am following the procedure outlined at http://www.unixtools.org/cvs/server-how-to.html to do this. Has anyone tryed this? Does it work? I guess will find out. 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. 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). But first decide what are your security goals? Securing root access and the OS? Securing the CVS repository? Foolproven authentication for changes to the repository? Outside the trusted users of CVS, and behind a corporate firewall, is pserver at an acceptable security level, how about pserver not running as root? What would make it a little better. I think a good explaination of how to run pserver as a non-root user would be good to have in the CVS manual. 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. Just my thoughts. Anyone have comments on the non-root jailed root wrapper to pserver from the web site above? Cheers, Mark > 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! __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ ___ 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
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