-
Improvement
-
Resolution: Won't Do
-
Major
Jenkins version: 2.32.2
Affected Role Strategy plugin version: 2.4.0
Summary: While the goal of the 2.4.0 version is "Dangerous permissions can be configured independently of Administer permission" there is a use case where you should consider allowable use of UploadPlugins to function without needing Administer to be checked. Within my team, we use chef to provide full configuration management of Jenkins. As such, in order to install plugins, this is done as anonymous - and chef has been able to do this without issue as long as anonymous has access to UploadPlugins. Anonymous for obvious reasons should not have Administer permissions. With 2.3.2 installed, the chef converge happens without issue. However, if we use 2.4.0 converge will fail:
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '6'
---- Begin output of "/usr/lib/jvm/jre/bin/java" -jar "/var/chef/cache/jenkins-cli.jar" -s http://localhost:8080 install-plugin /var/chef/cache/analysis-core-1.86.plugin -name analysis-core ----
STDOUT:
STDERR: [WARN] Failed to authenticate with your SSH keys. Proceeding as anonymous
ERROR: anonymous is missing the Overall/UploadPlugins permission
---- End output of "/usr/lib/jvm/jre/bin/java" -jar "/var/chef/cache/jenkins-cli.jar" -s http://localhost:8080 install-plugin /var/chef/cache/analysis-core-1.86.plugin -name analysis-core ----
Ran "/usr/lib/jvm/jre/bin/java" -jar "/var/chef/cache/jenkins-cli.jar" -s http://localhost:8080 install-plugin /var/chef/cache/analysis-core-1.86.plugin -name analysis-core returned 6
The error message is interesting:
STDERR: [WARN] Failed to authenticate with your SSH keys. Proceeding as anonymous
ERROR: anonymous is missing the Overall/UploadPlugins permission
This message is not entirely accurate, as this has already been configured for anonymous. What's going on here is that Overall/Administer has to be active in addition to Overall/UploadPlugins in order for this action to occur with this version of the plugin installed.
The ask for this JIRA ticket is either to:
- Allow UploadPlugins to function without the need for Administer to also be set in order to upload plugins
- Update the error messaging to clearly indicate that Administer AND UploadPlugins are both required in order for the user to upload plugins.
- is related to
-
JENKINS-43547 Add support of displaying effective global permissions on the Jenkins level
-
- Open
-
[JENKINS-43524] Improve diagnostics of disabled Dangerous Permissions
as long as anonymous has access to UploadPlugins
In such a case you may as well disable security on your instance, since anyone with physical access to the network can take over Jenkins with a couple minutes’ work.
Fix your Chef scripts to authenticate as an actual user with administrative privileges.
Yes, fixing scripts is a good approach. I suppose it is just a Jenkins 2 leftover. Though I wanted to confirm the issue is in just that before closing it
This is fair enough. Since the permissions will not be fixed, can you please consider updating error messages to clearly indicate to the user what permissions and settings are required? Right now, the output is inaccurate.
Observed:
ERROR: $USER is missing the Overall/UploadPlugins permission
Expected:
ERROR: $USER is missing the Overall/UploadPlugins and Overall/Administer permission
> ERROR: $USER is missing the Overall/UploadPlugins and Overall/Administer permission
It would be incorrect. User is missing the "Overall/UploadPlugins" permission only, because the plugin is just blocking it. I am afraid there is no way to easily update the text message though I could probably add logging of this warning. OTOH the administrative monitor should be warning you, no?
BTW, I created JENKINS-43547 to Security Inspector plugin in order to get better reporting.
CC danielbeck since the concern also applies to Matrix Auth
please consider updating error messages to clearly indicate to the user what permissions and settings are required? Right now, the output is inaccurate.
Well, the first UI access of an admin would inform them in admin monitors that their security config isn't as it would appear on the UI. So not sure how much that'll help.
(Oleg: There's an admin monitor on Role Strategy, right? Similar to what I did in matrix-auth?)
I'm sorry - let me clarify. Right now, if the user HAS "Overall/UploadPlugins" but does not have "Overall/Administer", this error message results. So, the current error message given is not accurate.
Point of view I suppose. The user is configured to have it, but the permission isn't granted. Little different from having Job/Build without Job/Read, you'll still be unable to start builds.
From a core perspective (which is what generates the error), Administer isn't actually necessary (which is why the change could be implemented in plugins only), so core is unaware of this additional limitation set up by the auth plugins.
We really tried to make this work, but dealing with bad design decisions from years ago that affect security, but some users have come to rely on despite that, are a mess to clean up.
I see nothing to be done here. There should be an administrative monitor displayed which advises you of the misconfiguration and guides you to correct it.
The improvement asked for is better in-line messaging for the case where the use focus is chef and console heavy, not UI heavy.
Well, currently admin monitors are displayed in the UI only (also in support-core diagnostic bundles). If you ignore security and other warnings displayed this way, there is not much we can do.
I wonder whether an admin monitors CLI command would make sense. Unfortunately output is tailored to HTML, so would need to be limited to visible yes/no.
The original request didn't mention the UI or admin monitors. The presumption on jglick part that I'm not looking at the UI monitor is not relevant to what is being requested. I totally get if there are limitations in the console output for the case I presented - please feel free to close this request out if the addition is not possible.
Thanks for taking the time to look at this.
The original request can be fixed neither in the plugin nor in core (at least not with any sort of reasonable effort). That doesn't mean you don't describe a problem it's worth investigating possible solutions for.
FWIW, this…
As such, in order to install plugins, this is done as anonymous - and chef has been able to do this without issue as long as anonymous has access to UploadPlugins.
… is a good example why we felt the need to implement this, and do it in a way that gives maximum exposure to the issue to make admins aware.
If you're able to upload plugins, then you can trivially write the give-my-user-admin-permissions.hpi plugin and upload it. Or the extract-all-valuable-data.hpi plugin.
Therefore, Anonymous should also not have any of these three permissions either, or all the users on your network have all the permissions, and can do whatever they want if they are willing to do the effort.
Yep, I totally agree on this point.
The reason for opening the issue was that the current setting will drive some users towards setting UploadPlugins AND Administer as a "fix" for this. It seems the changes made are regressive.
the current setting will drive some users towards setting UploadPlugins AND Administer as a "fix" for this
That's fair, but…
- We highlight the backward compatibility option both in the plugin docs (well, their wiki pages) and the directly security advisory. The idea/hope/delusion is that users who absolutely cannot go without will just do that, and nothing will have changed for them.
- They will be doing it very aware of what they're doing. You can't not know that you're granting Administer to anon, and setting a flag called "dangerous" to true is similarly unambiguous.
Previously, users may has assumed that, for example, granting Run Scripts is safe. In fact, I bring proof in the form of the Scriptler Plugin documentation (and that was written by a long time contributor to the Jenkins project who still was unaware what exactly he was recommending there): https://wiki.jenkins-ci.org/display/JENKINS/Scriptler+Plugin
You are able to configure whether you want to allow users which have only the "RunScripts" permission to execute scripts (every script has to be allowed separately). In addition you can also configure if these users should be able to change a script (which would be a security issue).
Now, at least, the unsafe behavior is opt-in.
danielbeck brenna_flood So do we need any actions here? From what I see, "no"
I haven't seen similar requests in response to the April permission changes, and of the 4 watchers, 3 are core team. It sucks that it probably confused brenna_flood for a while, but as I commented before, there are no straightforward fixes that I can see that wouldn't e.g. cause effective regressions. So spending time on this wouldn't really be time well spent IMO.
I am closing it for now.
If there are any particular improvements in diagnostics to be done, let's discuss them in follow-up tickets
You can enable the dangerous permissions using the "org.jenkinsci.plugins.rolestrategy.permissions.DangerousPermissionHandlingMode.enableDangerousPermissions" flag. Once you do it, the Administer permission will not be required.