Created attachment 124768 [details] [review] Patch which adds those listed variables Even though when pkexec is not designed to run X11 apps it shouldn't remove environment variables for GUI apps. They are needed for proper look&feel integration. GUI applications need the following environment variables forwarded: KDE_FULL_SESSION KDE_SESSION_VERSION DESKTOP_SESSION GNOME_DESKTOP_SESSION_ID XDG_CURRENT_DESKTOP QT_STYLE_OVERRIDE QT_XCB_FORCE_SOFTWARE_OPENGL QT_QPA_PLATFORMTHEME There are some more that may make sense to forward, such as KDE_IS_PRELINKED, QT_PLUGIN_PATH, XDG_DATA_DIRS etc., but some of those may be considered security issues. The ones in my list above are perfectly safe though.
remove 'DESKTOP_ENVIRONMENT' as it may contain '/' which forces pkexec to bail out [manjaro@manjaro ~]$ pkexec calamares The value for environment variable DESKTOP_SESSION contains suscipious content This incident has been reported. [manjaro@manjaro ~]$ echo $DESKTOP_SESSION /usr/share/xsessions/plasma
Created attachment 124770 [details] [review] Patch which adds those listed variables (v2)
From an one-minute look: * KDE_SESSION_VERSION: https://userbase.kde.org/KDE_System_Administration/Environment_Variables: > This allows one to know which kde?-config to run: kde${KDE_SESSION_VERSION}-onfig. explicitly recommending to use the variable in an unsafe way. (and /usr/bin/xdg-* programs really do that!) * GNOME_DESKTOP_SESSION_ID: Reportedly deprecated since 2009 ( https://bugzilla.redhat.com/show_bug.cgi?id=529287 ) * QT_STYLE_OVERRIDE: Apparently this can dynamically load plugins? Why is it safe? It might be, but the path lookup stack is too deep for a quick inspection or to be confident that it doesn’t pull from the current directory or so. * QT_QPA_PLATFORMTHEME: Similar, and there is even an explicit -platformpluginpath I’m sorry but this does not look all that obviously safe and I probably won’t have time to do a week-long research on this. Colin, if you know more, feel free to merge.
fwiw, I opened bug #96730 against xdg-utils to track this insecure use of KDE_SESSION_VERSION environment variable.
(In reply to Rex Dieter from comment #4) > fwiw, I opened bug #96730 against xdg-utils to track this insecure use of > KDE_SESSION_VERSION environment variable. Well, the code is using the variable _exactly as documented_; it is perfectly secure to use it within a session. It is just not secure to transfer the value across trust domains (like pkexec would).
(In reply to Miloslav Trmac from comment #3) > From an one-minute look: (to be fair, turned out to be 50 minutes actually :) )
I guess, how to move this forward: Basically there should be, for every instance, a reasoned argument why passing that variable is safe, ideally verifiable by third parties (you can assume that I know about nothing about KDE, and we can’t assume anything about future maintainers). That reasoned argument may have various forms, the only requirement is that it exists and that it is credible. For example: - Longstanding practice of passing that value around through privilege escalation points (like the `LC_` variables) - Explicit documentation by (the only plausible) user that the variable is safe to pass from untrusted sources (I can’t think of an example). - Manual verification of all relevant users and some argument that they won’t change. - Limiting the values to a strict range of clearly safe values. In particular that last one could be attractive because it makes the research very localized and trivial to verify. For example, limiting KDE_SESSION_VERSION to only three values "", "3" and "4" would be, I guess, obviously safe, and sufficient? Similarly COLUMNS/LINES limited to integers in range 10-200, with no leading zeroes or any funky formatting, could be fine. The PLATFORMTHEME/STYLE_OVERRIDE are worse, in that just limiting them to known theme names is alone not enough to demonstrate that plugins can’t be loaded from untrusted directories. Perhaps there is a simple way to ensure that?
given last comment let's close this.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.