[ On Thursday, August 5, 2004 at 12:52:10 (+0300), Delian Krustev wrote: ] > Subject: Re: CVS woes: .cvspass > > On Wednesday 04 August 2004 23:35, Greg A. Woods wrote: > > Nope, sorry, but that's just not possible, at least not with CVS pserver. > > What's not possible ? Using IPSEC ?! It's not possible to "secure" CVSpserver using IPsec. Period. I.e. it's just not logically possible, using CVSpserver, do do what you said could be done. To do so violates the fundamental security model of CVS and the Unix(like) systems it runs upon. IPsec can only secure the inter-host network links and thus make it possible to securely use CVS via remote job protocols such as RSH (which use host-level security techniques and assume their virtual circuits are already secure) instead of requriring SSH. IPsec does not operate at the user level and even if it did you'd still require unique system identities for every individual human user. Note that even pushing the IPsec implementation away from the host kernel and onto a gateway router implies blindly accepting many more assumptions about the security of the local area network. > I'm not sure what You mean by "human user". The whole point of security, i.e. authentication, authorisation, and accountability, is to relate all internal system activity back to real, verified, authorised, individual human users. I use the common phrase "human user" to differentiate the real people who use a system from the identities they assume, or rather are given, inside of a computing system environment. It is fundamental that each system account be used by one and only one unique human user. Without this condition accountability is impossible (at least for the users of that shared user-ID) unless it's provided by some external means (e.g. a security guard at the door of the Tempest-level room where the computer is located who is instructed to securely record every access to the computer, and who is capable of securely performing this duty). It is also fundamental that every system activity performed by a human user be performed using a unique-per-human _system_ level identity. If you do not meet this condition then you are violating the fundamental security model of the system and all bets are off, all warrantees null and void, etc. (note that a single human individual can assume multiple system identities without compromising accountability -- it's only not secure to have multiple humans assume a single system identity) > The users in cvs doesn't have > to be mapped to system users(CVSROOT/passwd). That's true at some level, but it's a (common) fallacy as well, and it begins with a faulty foundation from the get go. CVS only works securely with real, individual, unique-per-human, system level user-IDs, and where the CVS processes on the server run using the system identity of the human user they are acting on behalf of. If your human users are not using unique internal _system_ level representations of their unique identities then you have no secure ground to stand on in the first place. I.e. the mere concept of using cvspserver (and thus CVSROOT/passwd) is a non-starter if you are worried in any way about the security of your CVS repository. CVS users (the real humans using CVS) _MUST_ use unique system user identities in order that you can even begin to consider the state of the security of your CVS repository. CVSROOT/passwd entries do not equate to real system identities even if they map identically to real system identities because use of CVSROOT/passwd in that way implies running CVS as root and that's not secure in any way whatsoever (i.e. not by design and not by implementation). There are no if's, and's, or but's about it -- this is really _really_ fundamental computer security basics. CVS security, by design and by the way CVS is implemented, relies _entirely_ on system security and unique system level identities. Running CVS as root, or having all CVS users access one system account by way of CVSpserver with CVS running as that one system account, leaves CVS without any secure accountability whatsoever, while at the same time providing numerous holes big enough for CVS users to drive big Mac trucks through at each other, if not indeed also through to root level compromises in the former scenario. Like I'm sure I've said many times before, CVSpserver should never ever be used for anything but totally anonymous (and presumably read-only) access to a CVS repository, and hopefully that pserver accessible repostitory is also only an untrusted copy of the real CVS repository that the developers have write access to, and hopefully the system it runs on has the sole purpose of providing anonymous pserver access, or at least the identity it runs under is totally untrusted within that system. Let me say it again the other way around for the benefit of clarity: Only ever use CVSpserver for totally _anonymous_ access. > There's a site outhere. It's sf.net . They demonstrate, with the number > of projects being hosted there (with pserver access), You're not right > again. They demonstrate nothing of the sort (at least not with their CVSpserver offering). In the scenario you speak of sf.net has no real requirement for accountability -- their offerning using CVSpserver is effectively the same as providing anonymous access. Sf.net doesn't care who the real humans are in this case -- they simply do their best (which isn't always perfect) to keep whole projects from interfering with each other. (and their none-too-rare failings have been directly attributable to this particular mis-use of CVS -- i.e. their "lame" attempt to use CVS as part of their security infrastructure) Meanwhile, IIUC, sf.net does also offer secure SSH access to systems hosting CVS repositories and they use true system identities for eash SSH account, and presumably with this offering there's normally one (or maybe more) unique system accounts for every real human using this service, though of course the responsibility of verifying the uniqueness of system identities will be on the shoulders of the CVS project admins, and perhaps not on sf.net themselves. I.e. if two human users share an account there's only their peers within their project to account to and sf.net only attempts to provide the minimum level of _system_ security necessary for their users to police each other. Either way sf.net is a big enough target that if they have not implemented their services securely and within the security model provided by their underlying systems then we'll likely hear about the result here in this forum. > On the other side, people's stupidity is endless. I won't be surprised > to see private keys posted in a public forum. This, ofcourse, could > be nothing but a reason for admiration. No disagreement there! :-) -- Greg A. Woods +1 416 218-0098 VE3TCP RoboHack <woods@xxxxxxxxxxx> Planix, Inc. <woods@xxxxxxxxxx> Secrets of the Weird <woods@xxxxxxxxx>
