Re: patch to make CVS chroot
"TW" == Tobias Weingartner [EMAIL PROTECTED] writes: Unfortunately the way Unix is written there is no other way to gain access to setgid. If there were, my problem would be solved. If CVS had some other kind of group access control technology in it that would also solve my problem, but it doesn't. TW A normal login to the machine will work just fine. /bin/login (or TW whatever your platforms equivelant is) will actually do the setgid() TW (and a host of other things) for you. Why not use it? Because when you are sourceforge.net and there are several (tens) thousands of developers, things change it seems to me. --alexm
Re: patch to make CVS chroot
"LJ" == Larry Jones [EMAIL PROTECTED] writes: I've patched CVS 1.10.8 so that it supports a new command line option: cvs --chroot /some/chroot/root/ LJ Why do you want to add a command line option to CVS rather than just LJ using /usr/sbin/chroot in inetd.conf to run CVS? Because single cvspserver can serve several repositories. And I do not want to chroot(/home/cvs/) instead of chroot(/home/cvs/repos1), chroot(/home/cvs/repos2) etc. because those at repos1 hate those at repos2 and would give their little fingers to bring as much harm to each other as possible. Our task is to minimize that harm. It seems to me that this is the second case (first one is with authentication) where it becomes clearer that CVS is too much of a "system" itself and it can't rely on external utilities to do things that are usually considered "system". Virtual mail-servers (a-la vpopmail) are in the same situation. Vpopmail even has to do its own quotas, instead of relying on system ones, and there seems to be nothing you can do about this. In framework of current paradigm, sure ;) --alexm
Re: patch to make CVS chroot
[ On Saturday, August 5, 2000 at 15:49:21 (-0400), Justin Wells wrote: ] Subject: Re: patch to make CVS chroot WinCVS works very well with SSH on NT -- I've no experience with Win9x, It most certainly does not! It does. Even I could make it work with a very tiny amount of effort and I've not done anything serious with M$-Win for well over 10 years (i.e. back in the 2.1 days, around 1986 or so!). Do you want me to forward to you the 50 or so emails I got from windows users struggling to make it work? Do you know how many succeeded? Maybe if I flew to bulgaria or australia or brazil or wherever they happen to be then with some experience I could get it to work for them. If you put together a simple little canned configuration for them and published it along with other instructions you give to access your server then you'd kill 50 problems with one solution. But guess what? These people are volunteering their time and energy to my project. They aren't willing to spend any effort on making their WinCVS/ssh system work when it fails. They just give up and do something different and I lose those resources. Actually it sounds more like you'd do very well to loose their resources. Yes, I do know that not every good programmer is an expert with all the tools he or she is expected to use. However this is *VERY* basic stuff and anyone not capable of solving such miniscule problems is probably not able to solve other more important problems either. That's just unacceptable. I can tell you I tried your ssh solution for six months and now I'm running from it as fast and hard as I can before it kills my project. It's a disaster. It certainly does not work "very well". It's a failure. It's *YOUR* disaster -- your responsibility, to yourself, to fix it. You can hack on CVS if you wish but everyone in the know is telling you to figure out how to make it easier for your users to use SSH and so that you won't brind certain disaster upon yourself. Why don't you at least *TRY*! It doesn't matter how much effort *I* am willing to put into it. It matters how much effort the client has to put into it--NOT VERY MUCH. Obviously you're not thinking very far outside your box yet. Vapourware won't help me. Something that's been proven to work in production in professional software development shops around the worls obviously isn't ``vapourware''! Here are some simple facts. Pay attention: 1) I need to run pserver No, you do not. 2) I need ACL You will get sufficient ACLs iff you use real unix user-ids. 3) The patch I posted increases the security of pserver No, it does not -- it clearly and plainly *DECREASES* it! The cvspserver protocol is *more* secure *ONLY* if it *NEVER* runs as root. This can be done, complete with chroot, TODAY! You're right only in the fact that this particular combination might not provide the access control requirements you've imposed on yourself by choosing to run unrelated repositories on the same host. Sorry Greg, I tried it for the last six months, it just doesn't work. Maybe with a lot of fiddling it could be made to work on a client by client basis--but I don't even know who these people are, and they certainly aren't going to let me fiddle with their computers, even if somehow found the time and money to fly to Bulgaria or Brazil or Austrila or wherever to try. Here's a fact for you to digets: when I switched my pserver to ssh activity on my cvs repository dropped to near zero except for Unix people. When I reverted back to pserver interested picked up immediately. That's a fact. WinCVS/ssh just doesn't work, and if it can be made to work, it just isn't good enough for widespread use. You're obviously not going to get anywhere if you don't support your users sufficiently and appropriately. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: patch to make CVS chroot
[ On , August 6, 2000 at 11:21:35 (+0400), Alexey Mahotkin wrote: ] Subject: Re: patch to make CVS chroot Because single cvspserver can serve several repositories. Not securely it cannot! ;-) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: patch to make CVS chroot
[ On , August 6, 2000 at 11:12:01 (+0400), Alexey Mahotkin wrote: ] Subject: Re: patch to make CVS chroot Because when you are sourceforge.net and there are several (tens) thousands of developers, things change it seems to me. My meager little tiny systems can support millions of users (so long as they're not all logged in at once, of course). Sourceforge is a *perfect* target for attacks against cvspserver. So far they seem to only allow write access via SSH (see Justin, it does work! check out URL:http://sfdocs.sourceforge.net/ and in particular their sections on Win32/CVS/SSH), but they don't yet seem to have separated their writable repository from the anonymous access service provided through cvspserver. While they have the potential of having lots of integrity auditing, they don't seem to have any published formal procedures for ensuring the repositories they host are not compromised. If I had any say in sourceforge I'd encourage them to move read-only anonymous access over to a separate non-trusted system that cannot write to the live repositories (they could do this either with NFS and a couple of tiny hacks, or with regular CVSup updates, etc.) and I'd further encourage them to ditch cvspserver support entirely and set up unique (i.e. per-project) anonymous SSH accounts for read-only access. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: patch to make CVS chroot
On Sun, Aug 06, 2000 at 12:54:09PM -0400, Greg A. Woods wrote: Something that's been proven to work in production in professional software development shops around the worls obviously isn't ``vapourware''! Take off the "professional software development shop" training wheels and try to solve some real problems. Opening up your CVS repository to the world is a much more difficult problem, for several reasons. The first and foremost being that you don't get any control over the client setup. You will get sufficient ACLs iff you use real unix user-ids. I do use real unix user-ids. That's how pserver works. You're right only in the fact that this particular combination might not provide the access control requirements you've imposed on yourself by choosing to run unrelated repositories on the same host. I'm running only one repository on the same host. The fact is I have different classes of developers. Some people I trust to work on the core classes. Some people maintain only peripheral material. Again, take off the "professional software development shop" training wheels and try dealing with the more difficult scenarios. You're obviously not going to get anywhere if you don't support your users sufficiently and appropriately. I'd rather spend my time supporting them by writing code than supporting them by flying out to Bulgaria to get WinCVS set up with ssh. Justin
Re: patch to make CVS chroot
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Greg A. Woods) writes: See the recent thread on BUGTRAQ where someone "exposed" the insecurities of cvspserver. No. That's *not* cvspserver problem. First half is a general server problem not restricted to cvspserver and last half is client problem. They are not depended to cvspserver. I found that proposed fix for former problem or similar one are applied for sourceforge cvs server via ssh. (The result of valid-requests doesn't have Checkin-prog or Update-prog.) I think cvs distribution should have similar fix. You may think it is meaningless because cvs server with write access may provide shell access by definition, though. Sourceforge try to forbid executing programs other than cvs command on cvs server machine. Why cvs distribution shouldn't do similar challenge? -- Tanaka Akira
cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
"GAW" == Greg A Woods [EMAIL PROTECTED] writes: http://alexm.here.ru/cvs-nserver/ That looks like a really good idea. GAW Be warned that if used in the scenario where it provides "virtual GAW repositories" it suffers the exact same design flaws (and is thus GAW at least equally insecure) as cvspserver. GAW See the recent thread on BUGTRAQ where someone "exposed" the GAW insecurities of cvspserver. I've always thought that this is not limited to pserver itself. cvs over rsh/ssh should also suffer from this problem, because "Checkin-prog"/"Update-prog" are not parts of ":pserver:" protocol. They are parts of the "CVS client/server protocol", as described in cvsclient.info. ":pserver:" protocol covers only parts between "BEGIN AUTH REQUEST" and "END AUTH REQUEST", that consists mostly of sending login name and password. So the "design flaw" is just in so much trusting strings passed by remote clients and not in the :pserver: architecture, which is adequate enough. So when that will be fixed (and the simplest patch is included into the advisory), cvs-nserver will too be fixed. For now I will not release patched version of cvs-nserver until something more official about it comes out (cvs-1.10.9, for example). --alexm
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
The --chroot flag also significantly reduces the risk here as well. Only those executables you place into the chroot area are available for use. If you don't need scripts in your CVS installation you could also do without having any binaries at all--you could even place the chroot root in on a mount point that does not permit executable programs. In order to break in with the --chroot flag in place you have to smash the stack somehow prior to CVS dropping root privileges. After it's dropped privileges, it doesn't matter whether or not you can execute external programs: -- You can't write anything outside of the CVS area -- The chroot area may not permit executable programs I see this as a big win. Justin On Mon, Aug 07, 2000 at 12:09:47AM +0400, Alexey Mahotkin wrote: "GAW" == Greg A Woods [EMAIL PROTECTED] writes: GAW See the recent thread on BUGTRAQ where someone "exposed" the GAW insecurities of cvspserver. I've always thought that this is not limited to pserver itself. cvs over rsh/ssh should also suffer from this problem, because "Checkin-prog"/"Update-prog" are not parts of ":pserver:" protocol. They are parts of the "CVS client/server protocol", as described in cvsclient.info. ":pserver:" protocol covers only parts between "BEGIN AUTH REQUEST" and "END AUTH REQUEST", that consists mostly of sending login name and password. So the "design flaw" is just in so much trusting strings passed by remote clients and not in the :pserver: architecture, which is adequate enough. So when that will be fixed (and the simplest patch is included into the advisory), cvs-nserver will too be fixed. For now I will not release patched version of cvs-nserver until something more official about it comes out (cvs-1.10.9, for example). --alexm
subscribe
Josh Walker Behavioral Technology Labs http://btl.usc.edu "Better Living Through Simulation"
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
[ On Monday, August 7, 2000 at 00:09:47 (+0400), Alexey Mahotkin wrote: ] Subject: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot) GAW See the recent thread on BUGTRAQ where someone "exposed" the GAW insecurities of cvspserver. I've always thought that this is not limited to pserver itself. cvs over rsh/ssh should also suffer from this problem, because "Checkin-prog"/"Update-prog" are not parts of ":pserver:" protocol. They are parts of the "CVS client/server protocol", as described in cvsclient.info. ":pserver:" protocol covers only parts between "BEGIN AUTH REQUEST" and "END AUTH REQUEST", that consists mostly of sending login name and password. So the "design flaw" is just in so much trusting strings passed by remote clients and not in the :pserver: architecture, which is adequate enough. No, the flaw in cvspserver is that it effectively merges the identities of all unique users into one system level identity. Unfortunately since CVS relies by design on system level identities for accountability purposes, as well as for finer grained ACLs, these features are all lost with cvspserver. The "design flaw" in part comes from the fact that it's very difficult given the current protocol design to separate out the authentication and authorisation parts cleanly; and of course further arises from the issue that doing authentication on a modern secure multi-user system requires special privileges that should *never* ever be permitted of an application like CVS. The CVS client/server protocol was actually designed to assume that the connection it was using had already been properly authenticated and authorised, and not un-coincidentally that's exactly what RSH or SSH or something similar provide. So when that will be fixed (and the simplest patch is included into the advisory), cvs-nserver will too be fixed. For now I will not release patched version of cvs-nserver until something more official about it comes out (cvs-1.10.9, for example). The only "fix" for cvs-nserver is to completely remove the ability to support a non-system user. In essence this basically does away with the need for cvs-nserver in the first place so far as I can see (because it means all you're really doing is re-inventing SSH or SSL or SRP, etc.). -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
[ On Sunday, August 6, 2000 at 18:47:33 (-0400), Justin Wells wrote: ] Subject: Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot) The --chroot flag also significantly reduces the risk here as well. Only those executables you place into the chroot area are available for use. If you don't need scripts in your CVS installation you could also do without having any binaries at all--you could even place the chroot root in on a mount point that does not permit executable programs. In order to break in with the --chroot flag in place you have to smash the stack somehow prior to CVS dropping root privileges. After it's dropped privileges, it doesn't matter whether or not you can execute external programs: -- You can't write anything outside of the CVS area -- The chroot area may not permit executable programs If someone breaks your hacked chroot patch they will, by your design, have superuser privileges, at which point chroot is meaningless because anyone capable of doing the first crack will snuff your chroot in mere seconds and you'll be so fubared that you might not even be able to detect any problem for weeks, months, or even years! Read Phrack#54, for an example of how they can hide from you indefinitely. In fact it's practically script-kiddie fodder by now. Please learn to leave authentication and authorisation to the experts! -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] f
Re: patch to make CVS chroot
[ On , August 7, 2000 at 03:51:42 (+0900), Tanaka Akira wrote: ] Subject: Re: patch to make CVS chroot In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Greg A. Woods) writes: See the recent thread on BUGTRAQ where someone "exposed" the insecurities of cvspserver. No. That's *not* cvspserver problem. First half is a general server problem not restricted to cvspserver Yes, it is a cvspserver problem, and *only* a cvspserver problem. The number and consequences of bugs in any version of CVS not using cvspserver are totally irrelevant from a security point of view because the only way they can ever be exploited is by someone already authenticated and authorised to execute code on the server in question. This is because CVS, by design and implementation, assumes the user already has shell access. and last half is client problem. They are not depended to cvspserver. "client problem"? Perhaps you don't understand the limitations and implications of using SSH (or indeed any reasonably powerful client/server protocol implementation in a public network)? Sourceforge try to forbid executing programs other than cvs command on cvs server machine. Why cvs distribution shouldn't do similar challenge? Actually what they say is that they've replaced the shell on their server with a restricted shell that allows only SSH/CVS access. However they still face several risks since it is clearly possible to coerce CVS into executing rather arbitrary code on the server, not to mention that anyone who's ever experimented with restricted shells on traditional unix will know just how vulnerable they are to attack. The real protection comes from the fact that SourceForge have given unique system-level IDs to each developer and thus they can hold individuals responsible for any unauthorised activities -- i.e. activities contrary to their security policy. Security does not come about from technical means alone, but lack of sufficient and correct technical protections can make a security policy impossible to enforce. SourceForge have chosen the correct balance. Someone wishing to attack them would at this point be required to attack the authorised clients, and thus be able to covertly bypass SSH -- or in other words to use it to their own advantage without the knowledge of the user at the client side. There is still accountability in this scenario of course, but the users may not realise the level of responsibility they've inherently accepted! -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
sh script for debugging failed sanity.sh tests
I thought I was staring at the check.logs from some failed sanity.sh runs for way too long before spotting the lines which failed to match. Anyway, I wrote this script to solve the problem. It'll take the path to a check.log as an argument and tell you what's wrong with one of the patterns in it. It prints mismatched lines on top of each other too, which usually makes them much easier to scan. Pass in -a if you want it to try and match against the alternate pattern. I banged on it a bit and it seems to be reliable. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- He who laughs last thinks slowest.
[Fwd: sh script for debugging failed sanity.sh tests]
Whoops. I included the script this time. Might be nice in contrib. Or better yet, in sanity.sh so that the script automatically goes back and runs a line-by-line pattern check when the first one fails. Maybe I'll go back and do that later. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Don't confuse me with the facts, my mind's already made up! I thought I was staring at the check.logs from some failed sanity.sh runs for way too long before spotting the lines which failed to match. Anyway, I wrote this script to solve the problem. It'll take the path to a check.log as an argument and tell you what's wrong with one of the patterns in it. It prints mismatched lines on top of each other too, which usually makes them much easier to scan. Pass in -a if you want it to try and match against the alternate pattern. I banged on it a bit and it seems to be reliable. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- He who laughs last thinks slowest. debug.check.log.sh
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
On Sun, Aug 06, 2000 at 07:37:56PM -0400, Greg A. Woods wrote: If someone breaks your hacked chroot patch they will, by your design, have superuser privileges, at which point chroot is meaningless because anyone capable of doing the first crack will snuff your chroot in mere seconds and you'll be so fubared that you might not even be able to detect any problem for weeks, months, or even years! Read Phrack#54, for an example of how they can hide from you indefinitely. In fact it's practically script-kiddie fodder by now. This has *always* been true of pserver. It must start out running as root, and does not run any other way. If you try and run it as a non-root user it errors when it attempts to call setgid/setuid--with or without my patch. CVS pserver has always been script kiddie fodder, but my patch makes it much less so: WITHOUT CHROOT PATCHWITH CHROOT PATCH --- pserver must be run as root pserver must be run as root pserver might drop root pserver is guaranteed to drop permissions before invoking root permissions before invoking cvs commandscvs commands cvs commands might be used to cvs commands can only be used to read/write any file in the read/write files inside the limited entire operating system chroot area pserver might be used toexecution of programs can be execute any program on the disabled by chrooting to a system non-executable partition This is a *huge* improvement in security. It only applies to pserver, but it transforms pserver from a wide open barn door into something with reasonably good (but not perfect) security. Your argument seems to be that anything that is not absolutely perfect ought to be dropped. I'll accept that argument when people agree to drop pserver entirely from CVS--until then the chroot patch is badly needed. It sounds to me like you're just too stubborn to admit you're wrong. You can argue correctly that pserver is not perfect security and can never be made perfectly secure. However, so long as there are people who feel they have to use it, it is sensible to make it as secure as it can possibly be. Your argument against my patch boils down to "I hate pserver, please don't improve it." Ridiculous. Justin
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
On Sun, Aug 06, 2000 at 07:11:07PM -0400, Greg A. Woods wrote: No, the flaw in cvspserver is that it effectively merges the identities of all unique users into one system level identity. Uhh.. no. Read up on pserver. It performs a setuid/setgid to the user id of the user logging in to it. This is yet another advantage my chroot patch provides to pserver: you get to put a separate password file in the chroot area and have user ids that exist only for CVS, further isolating it from the rest of the system. And before you say it: remember the patch checks that you are non-root before proceeding, so you can't authenticate yourself as root somehow. Unfortunately since CVS relies by design on system level identities for accountability purposes, as well as for finer grained ACLs, these features are all lost with cvspserver. Uhh.. no. Read up on pserver. It performs a setuid/setgid so you can go right ahead and use unix groups and user identities to control access. The CVS client/server protocol was actually designed to assume that the connection it was using had already been properly authenticated and authorised, and not un-coincidentally that's exactly what RSH or SSH or something similar provide. It's also not coincidental that pserver performs the authentication separately and then hands control down to the lower level just as ssh would have done. No, pserver isn't sensibly implemented like ssh is. But it does the same thing. You don't do yourself any service by pretending that pserver has a different design flaw than the one it really does have. The only "fix" for cvs-nserver is to completely remove the ability to support a non-system user. In essence this basically does away with the need for cvs-nserver in the first place so far as I can see (because it means all you're really doing is re-inventing SSH or SSL or SRP, etc.). I thought nserver was implemented on top of SSL. But what do I know, maybe it isn't. Justin
[HELP] end of file from server problem when client in other domain.
hi, dear experts, i happened to a "end of the file from server" problem. below is my environment: server: NT 4.0, cvs NT 1.10.8 from client: win98, wincvs 1.13b, the network configuration here is rather complex. my win98 acts as NT client, its home domain is domain1. the cvs NT server is installed in another NT domain server, domain2. client preference: :pserver:domain1/userin1@cvsserver:cvsrepository login is o.k. cvs login (Logging in to domain1\userin1@cvsserver) *CVS exited normally with code 0* import is also ok. however, when i check out module, it reports error as: cvs checkout -P testdt001 (in directory c:\WORKS) cvs server: Updating testdt001 cvs [checkout aborted]: end of file from server (consult above messages if any) *CVS exited normally with code 1* if I use localuser in domain2, set preference as :pserver:userin2@cvsserver:cvsrepository, everything is smooth. what happened? any solution? thanks in advance! David Penn Shanghai Inst., Huawei Tech. Co. P.R. China [EMAIL PROTECTED] smime.p7s
Re: patch to make CVS chroot
On Sun, Aug 06, 2000 at 07:53:43PM -0400, Greg A. Woods wrote: Yes, it is a cvspserver problem, and *only* a cvspserver problem. The number and consequences of bugs in any version of CVS not using cvspserver are totally irrelevant from a security point of view because the only way they can ever be exploited is by someone already authenticated and authorised to execute code on the server in question. Get rid of the "professional software shop" training wheels please. I provide CVS access to people I don't know very well. I provide anonymous access to my CVS tree as well. In an environment like that it is *not* just a pserver problem. I need to make sure that, in the event one of these people turns out to be a bad apple, they don't get out of the box I've put them in. First, I use chroot to restrict the number of files they can read (and write) so they can't use CVS to romp through my whole OS. Second, I use Unix permissions and groups to restrict which files they are capable of altering inside that box. And please don't tell me that CVS would allow me to figure out who did what. Given a shell on the main root there are LOTS of dirty tricks you can play that don't leave too many tracks. It's very difficult to secure an entire machine against users with shells. It's not so difficult to secure them when they're locked in a little chroot with hardly anything inside of it. Your assumption that everyone who is authorized to access CVS is trusted in general is FLAWED. pserver plus the --chroot patch offer a workable solution to the problem. This is because CVS, by design and implementation, assumes the user already has shell access. And when you use the --chroot flag that assumption can be restarted as assume they have a shell inside the chroot only. Justin
