Sylvain Beucler <[EMAIL PROTECTED]> tapota :
>>
>> 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.
Would you like to do a test?
>> 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).
AllowTcpForwarding
Specifies whether TCP forwarding is permitted. The default is
``yes''. Note that disabling TCP forwarding does not improve
security unless users are also denied shell access, as they can
always install their own forwarders.
As sysadmin, you have unrestricted shell access. So there's no need
for you do something specific with ~/authorized_keys.
If you want to disable port forwarding, you should reconfigure your
daemon. I'm still unconvinced by the logic of using ~/ to store files
on which depends security.
>From the description of the sshd_config manual, it looks like
disabling port forwarding improve security. So I guess it would be
logical 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 |
+---------------------------------------------------------------------+
_______________________________________________
Savane-dev mailing list
[email protected]
https://mail.gna.org/listinfo/savane-dev
