-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 21 Apr 2007, at 6:09 pm, Derek Martin wrote: > The CVS support is marked as deprecated, because it may be possible to > convince cvs binaries to execute a variety of other programs through > "triggers"... The only way around this is to use rssh with a chroot > jail, and make sure no binaries you don't want people running are > inside the jail. Yucky. The only reason I haven't ripped support out > altogether is a lot of people are already using it, and objected to it > being removed, despite the concerns. You should probably only use the > CVS support if it's only going to serve as a CVS server (and > absolutely only use it in conjunction with a jail). Which is exactly what I use rssh for (and the way I use it). > I won't support Subversion because I don't know it, have no incentive > to learn it, and suspect it probably has similar pitfalls. I don't think so; CVS's main problem is that the user can cause arbitrary scripts to be executed if they have write access to the CVSROOT part of a repository. I can understand why this causes you issues Derek. Subversion specifically blocks that security hole; although it allows similar hooks to be created, crucially they are not part of the repository itself, and cannot be modified by users with commit access to the repository. They can only be modified by an admin on the machine. This is a considerable security improvement, in my view. >> There's a patch included in that bug against 2.2.3, but I expect it >> would require some updating for the current version. If you're >> interested in this, I could probably find some time to update the >> patch. > > 2.2.3 has a local root exploit. I seriously hope you're not using > it... That's the version that has been in Debian Sarge, but I think it had your fix backported. Debian *never* upgrades to new versions just to plug security holes, because additional bugs could be introduced. Instead, the fix is always backported to the version currently in Debian. >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323384 is a request >> for passwd support. The request was to disallow all command-line >> options so the person can only change their own password. No patch >> for this one. > > I have several objections to this. > > - I don't want to add it because I don't see the need. In most > cases, users will have access to other resources that share the > same credentials; it's better to change the password on a different > system and sync to the rssh server. That's not the case for a CVS server, typically (certainly not the one I run), and I suspect that CVS servers are probably one of the most widespread uses for rssh. > In cases where that's not > feasible, it's a fairly trivial matter to set up a web form to > change the password; I'm pretty sure there are already solutions > out there to do just that. Use one of those instead. In what respect is that more secure? I think it's probably much less secure, since it involves having to install a whole bunch more software, all of which has to be regularly monitored for security problems. > - If chroot jails are in use, it CAN'T work. The passwd command will > be run inside the jail, where it can not change the user's > password. The only way it could be made to work would be to keep a > copy of the passwd and shadow files in the jail, and periodically > copy the version in the jail to outside the jail. But that's a > huge no-no. Or you can do what I did, and use yppasswd inside the jail to change the password outside the jail through NIS. Works very nicely, and I don't think it's a terribly insecure option. Of course, we are all welcome to our own opinions on what level of security we require. In the case of the server I'm talking about, the users work in the rssh jail, and the NIS password that yppasswd changes is only for this one machine; the NIS server listens only to localhost, and the passwords are not used by any other system. The machine lives in the DMZ, and nothing on the system is allowed access to other machines - a separate firewall machine isolates it as much as possible from both our systems and the Internet in general. As you say, an individual admin has to understand the security implications of everything they do, and it's up to that person, with the people for whom they work, to decide what level of security/ functionality balance they require. And again, as you say, this has been gone over ad nauseam on this list in the past. Regards, Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD4DBQFGKkvhPN0/VuMTQjMRAri3AJjptGkomQWtenvSs24++5e/cmw/AJ9MdL4c gsXXOemG6Omc5oj86nbwJQ== =e7Ob -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ rssh-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rssh-discuss
