Review Request 126115: Unset environment variables before starting kwin_wayland

[Matthias Klumpp]

> On Nov. 19, 2015, 12:26 nachm., Sebastian Kügler wrote:
> > Possibly naive question: How would I use it with my custom-build setup, where I need vars like QT_PLUGIN_PATH, etc. set to be able to start the binaries at all?
> 
> Martin Gräßlin wrote:
>     I don't have a solution for it yet and yes it also affects my setup. I hope qt.conf can be used, but I don't know yet.
> 
> Matthias Klumpp wrote:
>     A possible solution to that problem is to allow setting this in a system-wide configuration file, or create a special KDE-specific configuration which sets the script to a "debug mode", which doesn't filter env vars.
>     The important thing is that you need root access to modify these settings (set it to debug mode or set additional variables).
> 
> Aleix Pol Gonzalez wrote:
>     Wouldn't specifying them in /etc/profile.d/ work?
>     
>     Currently I use it and it works fine:
>     ```
>     $ cat /etc/profile.d/kde5.sh 
>     source ~kde-devel/kdescripts/deploykde5.sh
>     ```

Not having tried this, it *should* work.
For Limba, which had a suid-root helper a while ago which was launched by the user, I once wrote a wrapper which filtered the environment and allowed only specific env-vars/values to exist. After cleaning up the environment, the wrapper execv'ed the real binary, replacing the wrapper process image with the real process. This has now been replaced with a much better solution not using this hackish approach anymore, but I wonder if it's something like this that we actually need, since this gives us full control over the environment of new processes.
(I am kind of curious now how GNOME handles this... Maybe I'll ask ^^)


- Matthias


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88591
-----------------------------------------------------------


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> -----------------------------------------------------------
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   startkde/startplasmacompositor.cmake 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20151119/e2af8f22/attachment.html>