[ On Friday, August 6, 2004 at 19:27:57 (+0300), Delian Krustev wrote: ] > Subject: Re: CVS woes: .cvspass > > Your mails are getting longer and longer. Please try saying more > in less words next time. Thank You. Unfortunately it seems I have to be very careful and very explicit with my words or else you evidently misunderstand what I am trying to say. :-) I.e. the more words I use the less likely you are to misinterpret them, assuming you do read them all quite carefully. ;-) > There's nothing like "fundamental security model". Not in unix/linux, nor > in CVS. I suppose You're talking about UID/GID based security. I'm talking about _the_ fundamental security model of unix(like) systems. And there certainly is one -- it's quite well known and very well documented, completely with a patent that's been signed over to the public domain. I don't know what _you_ might mean by the phrase "UID/GID based security". I'm talking about the basic concepts of computing system security and network security and how they relate to implementing a secure CVS repository on a unix(like) system with network client/server access. > I'll repeat myself. Security could be guaranteed on different layers. No, I'm sorry but you're still very wrong in this case. As I've already tried to say two different ways already it is simply not possible to guarantee any security whatsoever for a CVS repository using CVSpserver by piling together different, dis-contiguous, dis-connected layers of security on top of it. What you have proposed directly violates the, basic, fundamental, underlying security model of all unix(like) systems. You will be left with no accountability whatsoever. IPsec can only be used to protect virtual circuts that might happen to have to travel over insecure networks. However IPsec does not, and by design cannot, have any part to play in the user-level security required for implementing a secure CVS repository. Even using host-based IPsec and making the assumption that each user can be uniquely identified by the client host he or she is connecting from there's still no accountability for those user's actions on the server side when some poor afterthought of a hack like CVSpserver is used. SSH can also be used to provide the same level of protection, with the added fact that SSH integrates directly into the security model of the underlying system and thus no other security mechanisms such as those used by RSH are needed to use SSH with CVS (or rather SSH already incorporates those security mechanisms within itself). However SSH relies on the fact that in a secure environment every user will have a unique system identity just as would be done if CVS were used on a standalone non-networked secure multi-user system. > The local access to the repository requires each commiter to have direct > r/w access to each of the directories inside the repository. This gives > him the power to compromise it in anyway he likes. The commits performed > by locally executed cvs command are performed by creating/renaming/unlinking > files. Hmmm.... what you've said suggests that you need to go back and try to understand the basic underlying security model of the system that CVS was designed and implemented to run on top of before you consider the implications of what I'm trying to say. Note further that this model I'm talking about applies to many similar applications, including but not limited in any way to other file-based version control systems such as RCS, SCCS, TCCS, Aegis, and so on. Indeed as you say local access to the repository is required for each CVS user. In some scenarios it would indeed be easy for an authorised user to go in and mess about direclty with the repository files in order to compromise them. However the potential for compromise that you speak of is mitigated almost entirely by the nature of the application and how it is used. It is after all in fact the goal of CVS to provide mediated, shared, access to the common repository files. I won't go into how this mitigation works as all that's important in this discussion is to point out that it's not relevant to why IPsec does not, and cannot, do what you suggest. What this means though is that CVS, by design and by its implementation, relies _entirely_ on the underlying operating system for all of its security. As you hint CVS is no different in how it must be viewed from a security perspective than any text editor or compiler or spreadsheet calculator. CVS cannot safely be made responsible for the security of the repository any more than a text editor could be -- yet that is exactly what the CVSpserver hack attempts to do. Any and all ways of using CVSpserver try to turn CVS into the security application that it was not designed to be. Something like IPsec can only be used to provide security for the inter-host connections that might be used to interact with a CVS repository -- IPsec does not, and cannot, make something like CVSpserver into a security application. There's also a very blatant fact of history to consider: The evidence of CVS' failings as a security application have been splattered all over this very forum only quite recently, and it should be clear to anyone experienced with security software who has taken even a casual look inside of CVS that those previous compromises I refer to are only the tip of the inevitable and proverbial iceberg that anyone (mis)using CVSpserver is guaranteed to eventually run square into. CVS simply cannot ever be a safe part of any security infrastructure or application. It was not designed to do this and it was certainly not implemented to do this. Any and all attempts to use CVSpserver and/or other hastily cobbled together security hacks on top of the basic CVS code are bound to fail, sometimes catastrophically, and no amount of tweaking or auditing the CVS code will ever remove these risks sufficiently for such use. CVSpserver cannot, and must not under any circumstances, regardless of whether IPsec or similar is used with it, be used for anything but totally anonymous access to a copy of a CVS repository. Would you make your text editor responsible for authenticating and authorizing user accesses and accounting for their actions? Do you think IPsec could somehow make it safe to do this with your text editor? -- Greg A. Woods +1 416 218-0098 VE3TCP RoboHack <woods@xxxxxxxxxxx> Planix, Inc. <woods@xxxxxxxxxx> Secrets of the Weird <woods@xxxxxxxxx>
