On Sat, Apr 21, 2007 at 06:37:29PM +0100, Tim Cutts wrote: > > 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.
Perhaps, but as I mentioned I don't know the software, and have no incentive to learn it... > > 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. Ah right... That's kind of annoying, since the version bump in rssh is explicitly because of this bug being fixed. Nothing else was changed. This policy makes it harder for end users to know if their version is vulnerable... It's one of the reasons I don't use Debian except when I have no choice. > > 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. It's been true for every CVS server I've ever seen or run. :) > > 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? Unless the sysadmin is stupid, there are no suid root programs required to set up a web server. [/bin/passwd needs to be SUID root, but you already have that problem...] Also, existing web-based solutions for changing passwords theoretically would have that as their purpose, and theoretically would be well-tested from a security standpoint. You'd need to make sure you keep up with software updates, but the same is true of any security-sensitive software. > 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. Not really... every sane OS now offers some kind of auto-update feature. In most cases, the sysadmin need do nothing, beyond configuring that to run. I admit it does create another potential source of weakness to attack -- but so does adding this to rssh. And, you don't necessarily need to run the webserver on the same machine as the data you're trying to protect. For that matter, you could just set up a bastion host with an extremely minimal OS install, where users' shell is passwd, and they don't have any write access to anything on the system, except maybe /tmp (though I don't think you'd even need that). It could be a recycled 486 with a 1GB hard drive, which no one will miss... You could probably buy a machine for this purpose for about $25 if you didn't have one laying around... At that price, buy ten! If one fails, throw it away and replace it with one of the others. :) There are many, many ways to solve this problem, but I remain convinced that allowing rssh to do it is the wrong one. > > - 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. Your specific case looks OK to me (though I'd definitely want to think carefully about it before I set something like that up myself), but in the general case, NIS is *not* OK... it's completely insecure and unsecurable. In general, it should no longer ever be used. - passwords are transmitted in clear text on the wire - It uses (possibly broadcast) UDP, so it's easy to spoof - Any machine on the same network as the NIS master or slaves can spoof them, allowing local users to gain complete control of the NIS domain... Other than that, yeah... totally secure. ;-) I need to make this clear for people who are reading this and thinking, "oh, cool, I'll just get Tim's patches and set up NIS then..." > 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. This sounds reasonably safe, as I said; but you can't add a feature like this to the software based on such a special-case usage scenario. My other comments about that still apply. You need to jump through some pretty serious hoops to make this work in a reasonably sane way. You can't build a *convenience* feature in with such requirements, IMO. Solving the password problem is NOT easy, inherently dangerous, and IMO not worth doing (in rssh). -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
pgpaMdtgQVSoR.pgp
Description: 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
