> > 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. > > Would you like to do a test?
I did it; you should receive a message from [EMAIL PROTECTED] to [EMAIL PROTECTED] sent via cvs.gna.org shortly. Beware, I forgot to add a subject. I just received another test I sent to myself. Using the same SMTP transaction via a direct connection gives an error message saying that relaying is not permitted. > > 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") Not as far as I see; however, the command need to last long enough; since the port forwarding appears to end when the command completes. "cvs server" is a good example because it never ends. > > "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? That what was setup at Savannah, yes. But I guess we'll do it somehow else now. > >> - 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? Well, I used it for the time a few days ago, because my school's timetable page (edt.essi.fr) was attacked and is now unreachable fom the outside. Hence I had to setup port forwarding from the only machine that is reachable from the outside via SSH :) I admit I never used it at Savannah; however, speaking generally, port forwarding is not the only thing you can disable in ~/.ssh/authorized_keys, so you *may* want it to be activated only for a restricted set of users. Or run another daemon, which 'fixes' your concerns about implenting security in user files. > 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. Btw, I just saw that one can override environnement variable via authorized_keys. Fortunately this is only possible if PermitUserEnvironment is enabled in sshd_config. So I guess this kind of test could be removed. It might be good to include it in the frontend, so that user that inserted an invalid key would be warned directly. Same for GPG keys. But as you said this makes us code up-to-date analysis routines. So to sum up, - checking the key format is unnecessary and the code can be removed. - adding prefixes to authorized_keys is not a good design, one should rather run another ssh daemon for privileged users, and the code can be removed. I'll point Jim to this discussion so he can confirm. -- Sylvain _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
