<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/126115/">https://git.reviewboard.kde.org/r/126115/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On November 19th, 2015, 6:31 p.m. CET, <b>Matthias Klumpp</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Okay, I talked to some GNOME people (thanks!) to find out how they handle this issue, and the short answer is: Not at all
Reason for that is that it is really hard to fully secure the compositor if we allow apps to arbitrarily write to config files in HOME.
For example, one process might start to ptrace kwin, catching all input sent through it. Or someone might install a malicious KWin script. Or the bad app might install a .desktop file override in .local/share/applications overriding e.g. Firefox and then catching all the input. Etc.
Also, if the attacker went this far, they already have access to all files in the home directory and likely have reached their goal already.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">So, I think we can get KWin secure by adding some really heavy countermeasures (restricting it's access to $HOME, using a setgid bit on it's binary, ...) the question is: Is this effort worth it?</p></pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Thanks for asking.</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Not at all</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I already feared that this would be the answer</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">if we allow apps to arbitrarily write to config files in HOME.</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I don't think this is an issue in the case of KWin.</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">ptrace kwin</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">At least on Ubuntu one needs to be root to e.g. attach gdb to the process. Might be an idea to get this into all distros.</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Or someone might install a malicious KWin script</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">KWin scripts are fine (both QScript based scripts and effects). QML based scripts are problematic at the moment (will be hardened). QML based decorations (and decorations in general) are not a problem. I spent quite some time thinking about what is dangerous in KWin and what isn't ;-)</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Or the bad app might install a .desktop file override in .local/share/applications overriding e.g. Firefox and then catching all the input.</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">That's obvious, but our launcher got hardened against such things years ago (see https://www.purinchu.net/wp/2009/02/21/desktop-file-security/ )</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">they already have access to all files in the home directory and likely have reached their goal already</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I disagree on that. This was the approach on X - hey we don't have to do security, because heck X is broken anyway. I really think we should prevent the keylogger scenario.</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Is this effort worth it?</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Yes, if it makes it impossible to get a keylogger it's worth it.</p></pre>
<br />
<p>- Martin</p>
<br />
<p>On November 19th, 2015, 1:22 p.m. CET, Martin Gräßlin wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
<div>Review request for Plasma, David Edmundson and Matthias Klumpp.</div>
<div>By Martin Gräßlin.</div>
<p style="color: grey;"><i>Updated Nov. 19, 2015, 1:22 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
plasma-workspace
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Any environment variable which can be used to specify a path to a
binary object to be loaded in the KWin process bears the risk of
being abused to add code to KWin to perform as a key logger.
E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
that location would allow to easily log all keys without KWin noticing.
As env variables can be specified in scripts sourced before the session
starts there is not much KWin can do about that to protect itself.
This affects all the LD_* variables and any library KWin uses and
loads plugins.
The list here is based on what I could find:
* LD_* variables as specified in the man page
* LIBGL_* and EGL_* as specified on mesa page
* QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
combined with Qt's documentation
* "git grep getenv" in various KDE frameworks based on ldd output of KWin
Unfortunately the list is unlikely to be complete. If one env variable is
missed, there is a risk. Even more each change in any library might
introduce new variables.
The approach is futile, but needed till Linux has a secure way to start
the session without sourcing env variable scripts from user owned
locations.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>startkde/startplasmacompositor.cmake <span style="color: grey">(1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/126115/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>