BAD MSG: disabling port forwarding improve security. So I guess it would be ogical to disallow it, but if you can do a conclusive test of how it can be exploiting, by for instance using cvs.gna.org to send a mail, it would be interesting. (I already disallowed port forwarding on the others systems)
>> As far I can tell, port forwarding is a feature like X11 forwarding or >> else. It can be convenient to users but in no way it grants rights >> that would not be already given by the shell access they use. >> If it was not working that way, we could assume that ssh would be >> severely flawed, breaking security of almost 99% of servers using it >> -hard to believe. > > Since we are not providing normal shell access, we are expecting users > not to do anything else than CVS server. Opening a random socket is > something we have not really planned. In systems that do provide shell > access, either they have a way to check carefully who is sending mail, > either they block outgoing connections, or connections to the local > mail server (à la shell.sourceforge.net). But arent they bound to the command that got them the connection accepted in the first place (ie "cvs server") > >> So, to sum up: > > Let's sum up as well :) > >> - I do not think port forwarding could lead to security breach > > Ok, I think the spam example above is one. Interesting, but I'd like to be confronted with a real case, as it still puzzles me. > >> - If even it was the case, I do not think content of the >> authorized_keys would do any good because what is checked is the >> command asked, "cvs server" > > "cvs server" is not the problem, just a way to use -L. But if you are right, how the solution of writing stuff in ~/ fix it? Do you add a prefix specifically disallow port-forwarding? >> - I do not think it makes sense to rely on content of users ~/ to >> secure the systems. I'm a not saying users are entitled to a ~/ >> modifiable directly (on gna, users have basically no way to modify >> content of their ~/ apart using the web frontend) but I doubt any >> well written software was design to permit being secured by >> setting content in a directory by default user writable. > > True; I guess an alternate solution is to block port-forwarding in > sshd_config, and to open another SSH daemon for root/normal user > access, possibly on a different port (which is less convenient, but > well..). What would you loose specifically by blocking port-forwarding. It is something you use so frequently? Anyway, in gna case, it is not the same daemon that is used for root access than users access. > Also, regarding checking the key for "^(dsa|rsa)", it occured to me > that the authorized_keys options are only meant to add an additional > restriction. So I think there is currently no security risk in letting > user adding options in their SSH keys. I think that such test, if we want to do one, should be made in the frontend first. Otherwise, we would end up with a backend always failing to insert some keys, each time it runs. I wait for your demo about the possible usage of -L (quite a surprise, if this port forwarding is so powerful, that the option to block it is not even (even in comment) in the sshd_config default file). Afterward, I will anyway block it also on the cvs.gna.org, unless someone have good reasons to use it. If you are right, if this port forwarding allow to do unplanned activities on the server, I guess we'll have to add a note in sv_membersh to make sure people running sv_membersh know about this issue. Regards, -- Mathieu Roy +---------------------------------------------------------------------+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +---------------------------------------------------------------------+
