Subject: Can we make subsystems for robust?

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Mon, 18 Dec 2000 18:27:27 -0700

I would propose that we make a change to the definition
of subsystem so that subsystems are more robust and less
fragile.

I believe this is an old problem.  However, we've had
some recent experience with it.  If a user has something
in their .cshrc that produces output and the user attempts
to use sftp, the sftp client tries to interpret this output
as an sftp packet and the client fails without any useful
feedback to the user.

Sometimes the output in the .cshrc can be something very
subtle such as an escape sequence that changes the user's
xterm title bar.

Here are several possible solutions:

1) Change the draft to specify that only output from the
   subsystem is sent to the client.

2) Change the draft to specify that the subsystem will be
   invoked in a way that won't produce spurious output
   (i.e. the .cshrc will not be used).

3) Require all subsystems to send a 'start subsystem sequence'
   which would allow the client to discard all prior data.

4) Add a boolean flag to the subsystem request

   From draft-ietf-secsh-connect-08.txt:

     byte      SSH_MSG_CHANNEL_REQUEST
     uint32    recipient channel
     string    "subsystem"
     boolean   want reply
     string    subsystem name
     boolean   use user environment

   For backward compatibility, if the flag is not specified
   the value would be assumed to be true.

   If the 'use user environment' flag was false, the subsystem
   would exec'd without using the user's .cshrc (or equivalent).

   Then, individual subsystem specifications would specify 
   the value of this flag.  For example, I expect both sftp
   and the public key subsystem would specify false.

I welcome other suggestions on how we can solve this problem.

Is there consensus that we need to fix this problem?

I would like to rewrite the public key channel draft as a
subsystem.  If we don't change the definition of subsystems,
we will probably rewrite the draft using a variation on #3.
However, since I believe this problem is going to exist for
any subsystem, I would like to see if we can include a
general solution in the draft.

One more thought...

It may be possible that we should separate this into two problems.

1) Spurious output prior to the subsystem running can confuse
   the client.

2) Running the .cshrc (or equivalent) prior to running the
   subsystem may make it difficult (or impossible) to implement
   certain site policies since any arbitrary command can be
   run from a .cshrc.

Jeff P. Van Dyke
[email-masked]

---

From: Sami Lehtinen <[email-masked]>
Date: Tue, 19 Dec 2000 14:01:44 +0200

Jeff P. Van Dyke, on December 18. 2000, wrote:
  : I would propose that we make a change to the definition
  : of subsystem so that subsystems are more robust and less
  : fragile.
[snip]
  : Here are several possible solutions:
  : 
  : 1) Change the draft to specify that only output from the
  :    subsystem is sent to the client.

This is what I've been thinking about (ie. discard anything coming
from the subsystem-executable before the version packet).

  : 2) Change the draft to specify that the subsystem will be
  :    invoked in a way that won't produce spurious output
  :    (i.e. the .cshrc will not be used).

This can't be used (for obvious reasons).

  : 3) Require all subsystems to send a 'start subsystem sequence'
  :    which would allow the client to discard all prior data.

This would break filexfer (or at the least, sftp would be an exception
in subsystems).

  : 4) Add a boolean flag to the subsystem request
[snip]

Ugly ;) (I've protested against these kind of kuldges before. I don't
like these 'optional' fields, where it is arbitrary whether or not a
field needs to present.)

  : I welcome other suggestions on how we can solve this problem.
  : 
  : Is there consensus that we need to fix this problem?

Well, I don't think this is a serious problem (PEBKAC problem...), but
it probably should be fixed, as we're trying to make crypto easy to
use, and this kind of change would be to the right direction.

  : I would like to rewrite the public key channel draft as a
  : subsystem.  If we don't change the definition of subsystems,
  : we will probably rewrite the draft using a variation on #3.
  : However, since I believe this problem is going to exist for
  : any subsystem, I would like to see if we can include a
  : general solution in the draft.

If we can reach consensus on this, I will add 1) to the definition of
subsystems.

  : One more thought...
  : 
  : It may be possible that we should separate this into two problems.
[snip]
  : 2) Running the .cshrc (or equivalent) prior to running the
  :    subsystem may make it difficult (or impossible) to implement
  :    certain site policies since any arbitrary command can be
  :    run from a .cshrc.

Yes, but so you can run any command from any shell startup file
(.zshenv, .profile, whatever). And these are every time the shell is
used, so we can't fix this easily.

And, quite frankly, I don't see why we should. The administrator can
always change a user's shell. The problem at hand is a user/client
problem, and not related to security policy.

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Tue, 19 Dec 2000 09:03:15 -0700

> from the subsystem-executable before the version packet).

This sounds good.

Do we need to add language specifying the structure
and details of a subsystem version packet?

Jeff P. Van Dyke
[email-masked]

---

From: [email-masked] (Niels M�ller)
Date: 19 Dec 2000 10:34:59 +0100

> as an sftp packet and the client fails without any useful

That's a configuration error, which can break all sorts of things. I
don't think we should work around it in the protocol.

>    certain site policies since any arbitrary command can be

It seems to be an old tradition (on unix) that commands executed by
rsh are started with $LOGIN_SHELL -c "user's command line", where
LOGIN_SHELL is the shell listed in the passwd database, which implies
that any shell startup files are read first, and that the user can
manipulate the command execution by hacking the shell startup files. A
typical but harmless example: if a user runs

  ssh remote ls

and the shell startup files at remote contains

  alias ls='ls -F'

that alias is applied also to the command line executed via ssh.

It's not entirely obvious that this way of executing "commands" is
desirable or appropriate for subsystems. You could just exec the
appropriate subsystem binary directly, without invoking any shell. But
you have to be careful, as some sites may intentinally use /bin/false
or nologin for some accounts, and bypassing that could have bad
consequences.

But this is all implementation issues: I'd like to hear more comments
about it, but I don't think we should address in the protocol.

Regards,
/Niels

---

From: Markus Friedl <[email-masked]>
Date: Tue, 19 Dec 2000 23:15:20 +0100

> don't think we should work around it in the protocol.

yes, i think the protocol cannot care about user/sysadmin
configuration errors. having 'echo' statements in login
scripts for non-interactive sessions breaks a lot of things.

> or nologin for some accounts, and bypassing that could have bad

many sites do accounting / access control with the loginshell.
e.g. the loginshell just exits if the user is not allowed to
login, so, IMHO the loginshell should always be executed.

also, how do you know that a shell called /bin/false means
'deny login or subsystems execution' if you do not try
to execute  the shell.

-markus

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Wed, 20 Dec 2000 08:10:17 -0700

From: "Tero Kivinen" <[email-masked]>
> Jeff P. Van Dyke writes:
> I think this whole issue is implementation details and should not
> concern the protocol itself. There can be implementation hits saying
> that when you write your own subsystem you should add some kind of
> magic cookie in the beginning so you can ignore junk sent before the
> actual subsystem is started.
> 
> I think the specification of the version packet should be in the
> subsystem specification document, not in the main ssh document set.
> I.e the sftp specifies its own FXP_INIT packet and the other end
> should ignore everything before that.

Sounds good.

Jeff P. Van Dyke
[email-masked]