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

Robert Knight robertknight at gmail.com
Tue May 5 13:57:00 UTC 2009

To clarify - the one legitimate risk I can see here is that a program
started as the current user - which may or may not have been done with
the user's knowledge, may be able to send commands to a local or
remote terminal which is logged in with a different user and/or
server.  The login itself must have been done by the user manually and
must have required input from the user (such as login details and
password) which are not available on the machine itself.  So there is
no change in risk if the user already has a password-less login to the
target for example.

However it is not possible for a program launched remotely or locally
but not with the user's account to do this.  That is, if you run a
potentially malicious program as another user to 'sandbox' it in, it
won't be able to use this feature to run commands with your account

I think I'm inclined to agree with Arno here - if you already have
permission to execute arbitrary code with the user's privileges then
there already a lot of other avenues of attack.


2009/5/5 Arno Töll <lists at toell.net>:
> Lars Doelle wrote:
>> if i read the patch from 3/1/09 right, it allows to simulate keystrokes remotely.
> It does, true. This is however a feature, that already existed since KDE
> 3 days with DCOP. The whole DBus Interface is pretty much useless
> without this method, since only that allows to "script" a konsole
> session. This is therefore the most notable feature of konsole's DBus
> interface. Whe should discuss the term "remotely" however - konsole
> attaches itself to the session bus, where upstream just the local user
> has access this interface. So there is no way to gain access through a
> remote machine e.g. by using TCP or such. The session bus is just a
> local Unix Domain Socket only accesible by the user runnig the KDE session.
> I wouldn't consider this as a (real) security issue though, since it
> requires an local user wich deliberately executes a malicious
> script/programm to do something harmful. This is the same issue for
> _every_ executable being run by the user. I don't see why it should be
> more dangerous to allow an user to send commands through a method to a
> shell, against executing execve(1) syscalls or anything else that can be
> run from a shell effectively granting the same privileges.
> Or to say it different: why should anybody care about a DBus method,
> when allowed to execute own code on the local machine anyway?
> I agree however, there are potential issues when having local and/or
> remote sessions of shells with different privileges. But again: still
> you have to run malicious code by the user's will, and I don't think
> that we should consider this as one of konsole's problems just because
> the fact that konsole _allows_ different security contexts (which is
> essential for a shell I guess). You wouldn't either blame SSH insthead
> of the user using it, just because it _allows_ root logins?
> _______________________________________________
> konsole-devel mailing list
> konsole-devel at kde.org
> https://mail.kde.org/mailman/listinfo/konsole-devel

More information about the konsole-devel mailing list