Julian Opificius wrote: > > Todd Denniston wrote: > > > > Big question: What do you think using :pserver: at this point, gain you and > > your users over just :ext: over ssh? > > > > Because they already have (and will continue to have) valid system shell > > login, from here it only looks like more admin trouble to setup and maintain > > pserver, plus it probably reduces the authentication or authorization you > > had from the ssh and system level, especially when a new pserver hole comes > > out. > > > How does a hole in pserver reduce security? Is ssh protecting me or not? > I realize that all security is additive, but pserver would seem to be > no more than paint on the wall of ssh, meaning that if ssh goes down, > pserver won't help, but then again it won't hinder either. > > > > >>I have solved most of my admin problem by running admin users as their > >>themselves using $CVSROOT/CVSROOT/passwd entries like this: > >> "username:password" > >>rather than as the global cvs user: > >> "username:password:cvs" > > > > <SNIP> > > > > Why use the $CVSROOT/CVSROOT/passwd at all, just use the system > > authentication fallback, it SHOULD make your life easier because only the > > system level auth files need scrubbed when someone leaves not the system > > level AND all the cvs repos. > > > <Moved CHUNK to below> > > The only reason I am using pserver is that it allows my users to have > CVAS controlled access to the respositories without giving them dierct > write access to them. If you can suggest another way of doing that, I'd > be glad to use it. > > From a security perspective, my understanding is that ssh gives me > adequate protection from invasion from the outside world, (ssh is the > only port mapped through NAT to the server) and I have not yet > identified a need to protect my data from malicious intent from inside,
Actually you have apparently. You are attempting to prevent your inside users from directly accessing the repository directories. > so I'm not really sure what the risks of pserver over ssh really are. First lets reduce it to a pserver question, because after ssh is done everyone is 'on the inside' using pserver. As you say above pserver is letting you map all your users to one UID[1] which can read and write to the repository. As long as none of your users can login as this UID, none of them can 'fat finger' damage any files in the repository. However if pserver is compromised in a way that lets it become the special IUD and then allow an arbitrary command to be executed, the damage can still be done. Though to do it may require a malicious intent, the intent could come from either a user or a malformed client. IIRC at least one of the recent pserver holes would allow arbitrary command execution. [1] Actually I am pretty sure this is now not true, because you have taken off the :cvs on the end of your names in the $CVSROOT/CVSROOT/passwd. Originally I was interpreting your change to the $CVSROOT/CVSROOT/passwd file[1] to be all users, and if that was the case, then you had basically removed the one thing pserver was getting you, however I now see that it was only the admin accounts (which I hope are not doing double duty as developer logins) that became themselves. This misinterpretation is the reason I suggested that you had already removed your need for pserver. <Moved CHUNK> > The only reason I am using pserver is that it allows my users to have > CVAS controlled access to the respositories without giving them dierct > write access to them. If you can suggest another way of doing that, I'd > be glad to use it. As Far As I Know, you are correct, but at best you are only protecting them from a fat fingering while in the repository and do not have malicious intent. The first rule of the repository for users should be that if you are not the admin you never execute any non cvs command against it. The first rule of the repository for admins is back it up appropriately, as hardware/network/software faults can damage the work. With these two rules, I believe you should have at least as good a set of protection as pserver would get you, because you don't have developers with malicious intent and who follow the rules :} As long as the developers are using only :ext: cvs commands against the repository, I believe you should still be able to meet your FAA requirements: "FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server." but would be counting on the backups to prevent you from loosing any "lifecycle data", which is what you would be back to if they were looking at you with strictness when there is a known hole in pserver. In final, Yes using pserver will probably make it easier to "show" up front that everything meets the requirements, but in the past it has been the bain of security with cvs. I belive you are in the middle ground between the "restricted execution of CVS" Mark D. Baushke told you about, and the trusting developers ground of :ext: on a system they can execute more than cvs on. I further belive that you are only mildly protected from what you worry about, using your method. Where as one of the "restricted execution of CVS" would probably allow much more of the FAA level security lock down and logging. if you want further reading I suggest searching the list's archive for Greg Woods AND pserver OR Greg Woods AND authentication AND|OR authorization. I think the horse is dead, so I'll stop beating. <SNIP> > > As a final disclaimer: I'm an embedded software engineering manager, not > a network guru, and the network is a means to an end, not a reason to > live, so if I'm missing something, please feel free to snicker and roll > your eyes - as long as you then enlighten me as to what I "should" be > doing ;-) > I am also not a network guru, am only going by what I have read, so I also could be wrong. > Cheers! > > julian. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs