Review Request 126115: Unset environment variables before starting kwin_wayland

Thu Nov 19 16:37:58 UTC 2015

> On Nov. 19, 2015, 2:08 nachm., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for shell-defaults). You could then set exactly the variables you need, to the exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
>     No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
>     Just tried with changing directly in the wayland session file. That doesn't work at all. I think the main problem is that I lose important env variables related to the logind session/dbus, etc.
>     
>     So only way would be for the command to start kwin_wayland. But that as well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
>     Just gave a try - the command looks horrible, but I got the session started and env variables are properly filtered.
>     
>     Command looks like this now:
>         /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} XDG_SEAT_PATH=${XDG_SEAT_PATH} DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
>     Urgh, terrible! But I think this might just be the best workaround we can come up with, given the circumstances. It at least protects against someone adding new env vars which load bad code into the compositor. It might be an issue as soon as kwin starts to require another env var which isn't in the list, but that's an issue we can solve.
>     I wonder if we can simplify that command somehow, though, e.g. by placing the allowed variables in a file or new variable, to make this easier to read.
>     Apart from that, +1 from me (I'll take a look at other DEs though, maybe someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
>     Woundn't this break user's workflow? Since startplasma is started by kwin, the environment variable for the desktop will be derived from that.
>     
>     If distribution has some global configuration under /etc/profile.d (which is really common, e.g. openjdk, mozilla plugin path), they will not be set.
> 
> Martin Gräßlin wrote:
>     > Woundn't this break user's workflow?
>     
>     Yes, but what do you prefer? Breaking user's workflows or a secure system?
>     
>     There is nothing wrong of course with sourcing the env scripts in startplasma again and distributions using things like /etc/profile.d would be advised to do exactly that.
> 
> Alex Richardson wrote:
>     I don't see how this adds any security if you still keep $PATH. what if the user prepends `$HOME/my-evil-binaries/` to $PATH?
>     Maybe it makes more sense to restrict which scripts are executed before kwin launches?

Maybe starting a session manager as the first thing makes sense. That one can then spawn KWin and KWin can tell the service to start plasmashell when it's ready.
Reminds me that I wanted to redesign the KDE startup process a while ago, getting rid of most of the scripts. A `systemd --user` based startup could do the exact same, btw.
Unsetting most vars will break assumptions, but since this affects only Wayland, it's probably okay for a little bit of breakage to exist, although if we can avoid that we should try to avoid breaking things.
Generally I agree with Martin: Security >> Breaking Workflows >> Backwards-Compatibility

- Matthias

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

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/fb07a634/attachment.html>