cinnamon-schema scripts: harden against dangerous input#7670
cinnamon-schema scripts: harden against dangerous input#7670mgerstner wants to merge 1 commit intolinuxmint:masterfrom mgerstner:schema_scripts_security
Conversation
These scripts are supposed to be run via pkexec as root. The current implementation is very naive by trusting input parameters and passing them to cp and rm via a shell subprocess. This allows wildcards to be interpreted or path components to be added to the schema file to remove. This can lead to the scripts performing way different operations than originally intended. With this change a couple of attack vectors are addressed: - removal of files outside of /usr/share/glib-2.0/schemas is prevented - reading from special devices that could cause the script to block infinitely or to cause disk space exhaustion in the target directory is prevented - copying of files not owned by the user running pkexec is denied to prevent information leaks - copying of overly large input files is prevented
|
Maybe I'm missing something here but this seems a little bit overkill to me. The only place these scripts are ever used is in Spices.py, to install a schema that an applet, desklet or extension includes in it's installation directory. In that case I know of no way that code injection could be accomplished unless (maybe) the user tries to manually install a spice that is compromised, and in that case we give warnings that that method of installation should only be used by an applet dev to test his code. These scripts also can't be run without elevated permissions, so if something has the privileges to run this script, it wouldn't need to use code injection to accomplish it's nefarious purposes. Now, I'm no security expert by any stretch, but it seems to me that this is a really big change for something that isn't really that much of a risk, when we could just incorporate the functionality right into Spices.py itself and avoid the whole issue. Can you give me a concrete example of how someone could use this to cause problems for the average user without that user doing something that would leave it vulnerable even without the existence of this script? |
|
@collinss well actually I'm suggesting this as part of a security review for openSUSE (see openSUSE bug). I can understand the applicative view you have on this. However, you are using polkit as an authentication framework here and also ship polkit policy files (e.g. In this context the current script implementation would provide a privilege escalation. Hypothetical example: You just installed that cool Applet a minute ago and entered your admin password to install the schema file. Through Generally programs executed via pkexec with relaxed authentication settings need to be designed similar to |
|
@collinss on a different topic: I wonder why it is necessary to install those gsettings schemas at all into the system. Isn't there a way to keep them in a user's home directory? |
@mgerstner yeah, I was just wondering that myself. |
|
So I did some digging, and found that it is possible to install schemas to a non-system folder (eg.
I'm not sure if the first one is a good idea or not. I haven't really worked much with environment variables so I have no idea what best-practices are in that regard. The second one would require modifying all the existing applets that use custom schemas, but I believe it can be done so that it's backwards-compatible, so that may be the best course. |
|
After some discussion on the team we decided that at this point it's not really worth preserving support for this feature. Instead, we have opted to remove this feature and modify the 3 existing applets in our repositories that still use a schema file. |
|
Hello, everybody. @collinss: Just an FYI. The only disadvantages of not installing a schema globally, that I found so far, are that the schema cannot be exported/imported (with
What does that entails exactly? If it means that you will remove the ability to automatically install/remove a gsettings schema on xlet install/removal, I can live with that. But I really hope that you will not remove the ability to define an external settings application to use instead of the Cinnamon's xlets settings system ( |
|
We've left in the ability to define an external program. I realize there are alternate ways of using dconf that would have avoided system-wide modification, but we'd prefer to encourage the use of the xlet setting api, as it's much simpler all around to use, is user-specific, and avoids having to write your own gui to configure your applet. |
|
Hello, @mtwebster.
Thank you very much for that. I really appreciate it. 👍
I'm 100% with you on that. But, sometimes an xlet needs the power of a custom GUI to handle its settings because the native API isn't capable of certain things. And most importantly, building a custom GUI from scratch is super fun. LOL |
5 participants
These scripts are supposed to be run via pkexec as root. The current
implementation is very naive by trusting input parameters and passing
them to cp and rm via a shell subprocess. This allows wildcards to be
interpreted or path components to be added to the schema file to remove.
This can lead to the scripts performing way different operations than
originally intended.
With this change a couple of attack vectors are addressed:
infinitely or to cause disk space exhaustion in the target directory is
prevented
prevent information leaks