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?
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.
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?
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.
>From the manual description, I do not have the feeling that it allow
users to do things such as transforming a server into a gateway. For
instance, it is clearly specified that it is the local host (client)
that got a port forwarded, not that the server is to forward commands
or else.
-L port:host:hostport
Specifies that the given port on the local (client) host is to be
forwarded to the given host and port on the remote side. This
works by allocating a socket to listen to port on the local side,
and whenever a connection is made to this port, the connection is
forwarded over the secure channel, and a connection is made to
host port hostport from the remote machine. Port forwardings can
also be specified in the configuration file. Only root can for-
ward privileged ports. IPv6 addresses can be specified with an
alternative syntax: port/host/hostport.
So, to sum up:
- I do not think port forwarding could lead to security breach
- 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"
- 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.
>
>> > - SSH keys are recreated:
>> >
>> > * if the user_name contains a comma (,) - I'll fix this after the
>> > branch is merged, as promised some months ago
>>
>> But if user_name contain a comma, there's a bug, as it is not
>> legitimate in a unix name, is it?
>
> *cough* If the _realname_ contains a comma (eg Thomas Bushnell, BSG).
That was my guess :)
--
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
