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

[Robert Knight]

> I think current konsole development - as far as I followed it - tends to
> throw away any given system/platform dependend hack

The main motivation for keeping the amount of platform specific code
small is the assumption that the Qt engineers are better at dealing
with all the platform-specific quirks and behaviors than we are.  Have
a look at the kpty code for examples of the kind of #ifdef-mania I'm
glad we don't have to touch too often.  It is not because there is a
principal that we should treat all shells and platforms equally.  If
program-specific integration would add useful benefits, I'd be open to
that. Meanwhile, I also recognize that users' shell setups are quite
diverse and they would be upset if theirs didn't work at least as well
as it does in xterm.

Regards,
Robert.

2009/5/5 Arno Töll <lists at toell.net>:
> 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).
> _______________________________________________
> konsole-devel mailing list
> konsole-devel at kde.org
> https://mail.kde.org/mailman/listinfo/konsole-devel
>