[Konsole-devel] Konsole : Remote host executing local functions

[Daneel O]

Lars, thank you for your response.  Here is some more info to explain the
requirements and the justification.

AccuTerm is a powerful emulation program for Win32 only.  It allows
connection to multiple servers with many emulation types, through telnet,
serial line, or SSH, and includes powerful client-side scripting
capabilities.  It was designed to be used with Pick DBMS business
applications in corporate environments.  The audience is focused and there
is a 100% trust relationship between the server and the client - for anyone
who connects with AccuTerm to a server, it is understood and expected that
client-side operations will be invoked from the server.  This is a feature
and not a security hole.

There are other similar products in this Pick/MultiValue DBMS space, each
with their own scripting syntax and various value-add features.  This
paradigm is accepted by tens of thousands of users worldwide, that a
business application which can drive the client environment is more
powerful and thus more desirable.

As the Linux desktop is starting to mature and companies are considering it
more for business use as an alternative to Win32, people are starting to
look for the same features in Konsole that they've enjoyed in these other
products for almost 20 years (even the DOS versions of these programs had
similar features).

Konsole is now used by a general audience where there often no such trust
relationship between the client/user people who own the server.  In a
business environment it can be used over an intranet or extranet where
people wouldn't think of using it for any non-trusted server.  In this
environment the end-user is a business worker, not a programmer, geek,
hacker, sysadmin, or your traditional Linux user - and after all, isn't it
the goal of Linux developers to get the KDE into the hands of this very
mainstream target audience?  So I think those who maintain software like
Konsole need to start looking at the other side, and while being vigilant
about security, also be careful to not avoid adding features because there
is potential for abuse.  Lack of features is what has held the Linux
desktop back from maintstrem adoption.

Here are examples of specific features that we would hope to see, and
again, which I can probably get funded.  In all cases, the bottom line is
to allow a specific escape sequence from the server to evoke behavior on
the client.  For example:
  ESC STX < command CR
This will cause Konsole to execute "command" in a shell using the current
user permissions.  Scary, yes, but that's what people want.  This
particular version will return back to processing immediately (non-modal) (
#cmd & ).
  ESC STX > command CR
This executes a command in a modal fashion, not returning control back to
the session until the command is finished.
  ESC STX U p m ; path CR
This will upload a file from the client to the host using protocol 'p'
(ASCII,X/Y/Zmodem or to be determined) in mode 'm' = T/text or B/binary.
  ESC STX C o p t ;path CR
This captures screen output to a log, mode 'o' is Overwrite, Append,
Newfile only, or Clipboard.  Source 'p' may be P to capture printed data or
null to capture received data. Option 't' may be for Text only or null for
capturing all raw data.
  ESC STX C X     --terminates capture
  ESC STX I
Returns information to the server (captured through stdin) about the
specific client release.
  ESC STX ?
Returns a string indictating client platform, capabilities, etc, so that
the server knows what sequences can be invoked on the client.
  ESC STX Y path CR
Sends the current client clipboard to the host.
  ESC STX P statements CR
You'll probably choke on this but that executes raw VBA statements in a
Win32 client.  For Konsole this could assemble a shell script, Perl, Tcl,
and even display GTK windows using whatever bindings are available.

Note that these features are not at all specific to my Pick/MV home market.
Consider how  developers could use features like this to integrate with
OpenOffice, Konqueror, and other applications, where the server canbe used
to invoke real use out of the client/KDE environment.

To keep this from forking from the Konsole base it would be important for
Konsole to start in a feature-disabled mode, where the user must
specifically enable the features for a specific server.  So traditional
Konsole users would not face a risk from untrusted servers.  There is no
need to toggle specific features on/off, it's accepted that if we trust a
host that we will accept whatever features that host is going to invoke.

Technically I know all of this is possible.  I can read the Konsole source
and I see where to put the hooks, but I lack the technical skills to
implement the changes.  Assuming someone is willing to implement some of
these changes, and the Konsole developer(s) will accept this code into the
base, then I can provide guidance for implementation.

Please feel free to ask any questions.  I know this challenges your notion
of how Konsole should be allowed to function, but these features can help
to make it an integral part of many business applications, and thus expand
the audience.

Tony

---------------------

lars.doelle wrote:
> Tony, Kurt, All,
> 
> On Tuesday 06 September 2005 22:01, Kurt V. Hindenburg
> wrote: 
>> On Sunday 28 August 2005 18:12, Tony Gravagno wrote:
> 
>>> anyone who wants it.  It can be added to the standard
>>> code base or it can fork to a separate open source
>>> repository so that existing Konsole users don't feel
>>> vulnerable to trojans from untrusted servers.  But for
>>> those who want the features bad enough, I think they're
>>> going to have to commission the development effort and
>>> subsequent support, or they simply won't get what they
>>> want.  
> 
> Tony, it actually did not become clear to me, what they
> really want. But if the issue is:
> 
> - on host A: open a telnet connection to host B.
> - on host A: enter a command to be started on B.
> - on host B: the command wants to do something on host A
> during its execution. 
> 
> Then, the normal way to do so is to delegated the command
> from host B onto host A using ssh. If a command such
> executed produces output or demands for keystrokes, all
> is already perfectly arranged. 
> 
> I.e.: Call back using _another_ line. Do not (ab)use the
> line of original telnet session.
> 
> It is because this procedure requires an authorization,
> in which host B makes clear to host A that it is entitled
> to execute commands on host A. 
> 
> The point is, that this right cannot assumed to be
> granted by logging into host B and executing a command
> there. 
> 
> (Use ssh-copy-id from host A to host B to grant that
> right if you do not like to acknowledge it per instance.)
> 
> (If the command shall additionally be executed
> immediately on login to host B, one could arrange such
> using .bash_login or another configuration file for the
> login shell on host B, for instance.) 
> 
> None of these solutions do need any modification of the
> konsole. It appears they have more a kind of a remote
> scripting problem, stumbling over security barriers, as
> they should. 
> 
> 
>>> While you indicate that driving a localhost from a
>>> remote host is not already in Konsole, it seems to me
>>> that it would be pretty easy to make this happen.  I've
>>> provided a link to my notes on this here:
>>> http://tinyurl.com/7ffrq  You can read up from that
>>> thread to see how this subject unfolded. 
> 
> Yes, it is easy to do. It was never included into the
> konsole for security reasons. It's absence is a feature,
> not an omission. 
> 
> In general, it is an extremely bad idea to a allow a
> terminal to change anything on the localhost but its
> screen.  Not always obvious, even the most innocent such
> "features" are only security holes by their very nature. 
> 
> For instance. From the dos times, i remember that the dos
> ansi implementation allowed to set the key sequences via
> escape codes, a "feature" intended to allow to adapt the
> function keys to the needs of the (remote) application.
> This means, it was remotely possible this way, to set the
> return key to emit something malicious like "del *.*\n"
> immediately before closing the remote session. 
> 
> Likely, zmodem (an ancient file transfer protocol) has
> had specified (but hopefully never implemented) options
> to execute commands on the client, i.e. it could do
> likely damage. Only imagine an internet where http , ftp,
> smtp, telnet, ssh, just any, would be allowed to do on
> the client side what the server side wants.... 
> 
> Same holds for the konsole, only perhaps, for a little
> less obvious reasons. 
> 
>> You might try to post a clear and consist email to
>> kde-devel mailing list and see if you get any
>> replies/suggestions. 
> 
> Yes, it is a bit unclear, what the problem is. Don't
> hesitate to write via private mail or keep posting on the
> list if you think it is a konsole or kde issue not
> properly understood by us. 
> 
> -lars