Bug 96713

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.