On Tue, Jan 04, 2005 at 11:29:07PM +0100, Mathieu Roy wrote: > Sylvain Beucler <[EMAIL PROTECTED]> tapota : > > On Tue, Jan 04, 2005 at 12:04:06PM +0100, Mathieu Roy wrote: > >> > Incidentally, one can use port forwarding at Gna!, hence make Gna! do > >> > unwanted connections, for example: > >> > > >> > $ ssh [EMAIL PROTECTED] -L 8080:www.gnu.org:80 "cvs server" > >> > $ links http://localhost:8080 > >> > > >> > So, the feature has some usefulness, allowing to make a kind of > >> > special sshd_config for Savane-managed users, but I hesitate about > >> > including it. > >> > >> Hum, as we provide ssh access, I guess we can assume that using -L is > >> ok. Shouldn't we? > > > > Not sure; especially in the case where Gna! is used that way as a > > gateway to perform an attack or other nasty things. > > > > Likewise, we provide SSH but we do not provide shell access. > > > > What do you think? > > I am not sure to understand your example. In your exemple, you asked > for a CVS server command. A command you must allow anyway in order to > provide CVS over SSH. > > So one can do port forwarding with a legitimate command. What's the > point? What the problem?
The problem is not "cvs server", it is the -L option (that can be done only if I can execute a valid remote command. Then, I think one can do -L8080:mail.gna.org:25 and send spam from inside Gna!, for example. > Saying "we provide SSH" looks meaningless to me. You provide different > kind of access _with SSH_. If you force usage of a command inside the > authorized_keys files, you give a shell that can only run this > command. You are still, somehow providing a shell. True. > Now, one someone can perform an attack with a "cvs server" command, > and how can you provide ssh access without allowing "cvs server" > commands from authentified users? You still provide cvs server, but you then disable port-forwarding. And since, as a sysadmin, you may need port-forwarding for your own needs, it may be a solution to put it in users' ~/authorized_keys instead of in sshd_config (but see below). > 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). > 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. > - 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. > - 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..). 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. -- Sylvain _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
