-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unsafe Installation #102
Comments
Very good that you spotted it, it's very important that we fix this! Moving |
The current idea is to add a Makefile to the project with the following targets:
extensions.gnome.org workflowInstall it via extensions.gnome.org, where the extension will install the Admins remote install per user workflowLogin to the remote machine and run Admins remote install global workflowLogin to the remote machine and run Package maintainers workflowSame as admins remote install global workflow. Developer workflow (Option 1)Clone the git, make your changes, and run Developer workflow (Option 2)Clone the git directly into Why a separate
|
I started working on this |
Look at #107 for progress |
This tool should not be touching anything outside of |
If I get this right, you are missing a The core problem of this is that one generated polkit rule only works for a specific installation path of the extension. If the extension got installed system wide or by another user, you need a different polkit rule as when the extension got installed via the gnome extensions website. This is to prevent file collisions on multi user systems where each user installs the extension individually and to prevent privilege escalations from other users on the same system. However, we could provide a complete extractable tgz for system wide installations only, in the Github releases download section. This tgz contains the shell extension and the corresponding polkit rules for a system wide installation. Also, we can provide a I would prefer distros to ship this extension. Maybe I'll find the time to create Gentoo and Fedora packages... But I hoped others would get on this as we are mostly lacking time to package for all the distros... |
This is a really important security issue. I think we should change the installer to install
cpufreqctl
into/usr/local/bin/
.Allowing users to run scripts installed in the user folder is completely unsafe, effectively providing root privileges to any program running as the current user.
Example exploit, run as the user:
Instead, the installer should drop
cpufreqctl
into/usr/local/bin
or rely on a system program.These lines attempted to fix the issue, but directories that are writeable can have its files renamed.
This also happens to fix #95 😄
The text was updated successfully, but these errors were encountered: