[Konsole-devel] KDE 4 Konsole DBus works -- security objections, privilege escalation possible

[Arno Töll]

Lars Doelle wrote:
> Hmm, the problem addressed appears to be that session management does not
> extends into the bash and from there into the individual programs. Of course it
> would be nice to have vim session being saved with logout and restored on login
> again, all with an mc session around it. I sometimes think, i could ask the bash
> authors about it...

I think that might be a great feature, but this topic has indeed to be
adressed to the bash maintainers. Altough a great idea it is somewhat
different of what I'm supposed to do with a sendText() method (which is
still limited to a output only unidirectional pipe like behaviour).

While not speaking for the konsole maintainers, but for myself only, I
think current konsole development - as far as I followed it - tends to
throw away any given system/platform dependend hack. KDEs effort to be
ported on more architectures results in a wider variety of konsole users
  , so there won't be introduced (new) hacks to konsole which would
depend on Linux/bash/vi/whatever. Probably Robert or Kurt could say more
here.


> If one wants to solve the particular use case above with automation, a far more
> secure variant is to start a session with a command provided. 
[..]
> | int ViewManager::newSession(QString command, QString profile, QString directory)
> 
> might do what you want. 

How would you do this with a predefined command and/or profile using
newSession():

- open three new tabs, label each with a hostname
- open a remote connection to three remote machines (thus by using "ssh
user at hostname as newSession(command) anyway. Authentication is left out
to the user here at this point, requiring key-authentication or
ssh-agent or such)
- sendText("apt-get upgrade) on each session
and - now comes the important point:
- the user sees what happens on each terminal and can interact
interactively, i.e. type "yes" to continue or to type any other command
he likes to reuse this session for any given use. Note, the big
difference to a static predefined unidirectional batch-like command
processing, as pssh provides or as a command to be executed as session
start would do.

The key feature of sendText() is to fill the gap between an automated
aid for some often experienced tasks but still let user keep the full
control of the session (I'd put 'apt-get --quiet --assume-yes upgrade'
to the crontab for my use case otherwise, if I'd like automated
non-interactive processing)

It prevents privilege escalation since the command would
> be started with the rights under which the konsole is runs. It you want to provide a
> password with the command, do so, or use ssh-copy-id. 

It doesn't prevent anything. Let's assume the case you explained before
(an attacker could execute arbitrary code on the local machine). So he
could still create a new malicous profile and execute it with
newSession() or just wait until you spawn a new tab. If I'd exploit your
local machine by adding a new default profile for your KDE konsole with
this command:

echo 'alias su="echo 'owned'"' >> ~/.bashrc && bash

You wouldn't even notice, and the next time you type su I've got you.
All I need is the newSession() method from konsoles DBus interface to
inject that command (which seems ok to you, opposite to sendText()). In
fact I don't need DBus at all to inject this malicous command to you
local system, once I've gained local execution privileges.

To come back to Robert's and my argument: as soon as you can execute
arbitrary local code, there are much easier ways to gain privilege
escalation, even without sendText().

> If automation goes beyond
> the start, the ssh could start a remote script ending in shell session.

Altough possible, this is a pretty static and annoying purpose once you
have this to do on every single machine you potentially want to
administrate. Just to give you an idea:

arno at snowball:~$ wc -l .ssh/known_hosts
957 .ssh/known_hosts

I find it _much_ more comfortable to have one central place, where I can
manage my shells and commands I want to execute in an automated manner.

> Or do i understand your use case wrong?

Well, yes. Just take a look on sshmenu to see, what it allows me to do.
But I just won't insist too much on my particular use case, since I
didn't write the DBus patch for my special use only. I really think
there is a lot of more useful use cases for the sendText() method.

> If you want to "extend" the bash somehow ("I'm not limited to bash like command
> processing as in pssh"), i believe it safer to do this from within the individual session.
> If you have such a case, I'm interested to learn about it.

I did mean bash as a simple line by line command line processor. Again,
what you suggest, and what already existing solution for my use case do
is (somewhat simplified) in pseudo code:

foreach $shell in @shell-list
{
    $return-status = execute("command")
    if ($return-status != 0)
    {
       croak("Something went wrong")
    }
}

that is a static, non-interactive command processing. It basically
allows you execute any given non-interactive command (e.g. "uptime",
"date", ...). But what I do (and want) is somewhat different. For
example assume the following session (still my apt-get example):

foreach $shell in @shell-list
{
    $pid = execute("ssh foobar at remote.host")
    if ($pid > 0)
    {
       sendText("apt-get install apache2 && vi
/etc/apache2/sites-enabled/default")
       # let me, as user, take over this session so far automated
    }
}

The key feature is, that I can tab through every session, check apt-gets
ouput, type "yes", continue with install and then take over the session
by editing my configuration files by hand without losing time by open
every shell in a tab, configure "copy input to" in konsoles settings,
and type my command).