--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/lThSifB8G4k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3bf1bdfc-2263-4d8b-be56-8c41d9975a61%40googlegroups.com.
Currently, when using matrix style authorization, an administrator may choose to selectively remove the ability for a user to RUN_SCRIPTS, UPLOAD_PLUGINS, or CONFIGURE_UPDATECENTER. At first glance, this may seem reasonable, but any user with one of these permissions must also have been granted ADMINISTER. If a user has been granted ADMINISTER, they can also grant themselves any of the other permission types. Furthermore, this behavior may not be intuitive to all administrators, resulting in inadvertently granting more access to a user when the intent was to actually limit their access.
We propose deprecating the permission types RUN_SCRIPTS, UPLOAD_PLUGINS, and CONFIGURE_UPDATECENTER, to be replaced with the existing ADMINISTER permission (which they effectively are, or easily allow a sneaky user to elevate themselves to).
Additionally, we want to introduce a new permission type, CONFIGURE_JENKINS, with the intent of seperating configuration elements that do not allow a user to escalate beyond what was given to them from those that impact security on a global level.
This means that access to configuration urls such as /configureSecurity/, /configureTools/, and /pluginManager/, etc, as well as certain elements under /configure/, would only be visible/accessible to users who have explicitly been granted the ADMINISTER permission.
Other configuration urls and elements would be accessible to users who have been granted the lesser permission of CONFIGURE_JENKINS (which would also be implied by having the ADMINISTER permission).
The above example is not meant to be an exhaustive list, and we would appreciate feedback and discussion as we work to flesh out the details in our draft JEP. Our guiding principle is that the configuration being changed should not allow the user to escalate to do something that they would not normally be able to do if they just had CONFIGURE. We are also aware that a change like this has the potential to impact many plugins, and we are working on assessing what the scope of the impact would be.
I wonder whether it would make sense to (optionally) allow use of the plugin manager. With an admin-configured update site only offering curated plugins, it could make sense to allow Configurers to update or install plugins themselves. (Basically retaining the legacy distinction between doing only that, or having permission to change proxy configuration or upload plugins.)
On Mon, Nov 25, 2019 at 2:03 PM James Nord <jn...@cloudbees.com> wrote:
> IMO [installing plugins] should be another Permission
Just seems like permission bloat. I would expect `CONFIGURE` to imply
the ability to install or update (but not downgrade) plugins from the
UC.
> for example if you have a curated locked down blessed update center you may want to allow someone to install plugins from that without the ability to configure jenkins (pipeline steps would be one example, of plugins that can store their configuration at the folder level and do not need global config).
While there are certainly plugins which do not require any global
configuration, adding one sounds like configuring Jenkins to me. Why
would an administrator wish to allow installation without
configuration?
> At the same time just because you can configure the system message does not mean that you should be able to install new plugins.
`CONFIGURE` means a lot more than setting the system message, I hope.
And if you have this curated update center then what is the harm in
letting a configurer install plugins from it?
As part of this proposal we have been struggling a bit to find the
right "name" to describe this new permission type. Currently, we are
thinking about creating a new Permission Group
called Restricted Administer
in order to provide some contextual meaning to the permissions it
contains. Initially there will be only the proposed permission, Configure
,
but there are a number of other potentially similar permission types
that would fit in this category as well (although not in scope for this
JEP). Below is a screenshot to help illustrate what we are considering.
note: the additional permissions shown below are just to help make the picture a bit more clear. TBD how permissions like Read Only
will work in conjunction with others, etc. The primary focus is on
deciding on the terminology to best describe these types of permissions
in generally
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7c9ba96b-1626-4af1-9964-bdad58bbb453%40googlegroups.com.
Plugins that contribute to the settings on on the
Configure Jenkins
page should carefully consider if allowing a user with onlyJenkins.CONFIGURE
could result in an unintended privelege escalation.
Plugins that contribute to the settings on on the
Configure Jenkins
page should carefully consider if allowing a user with onlyJenkins.CONFIGURE
could result in an unintended privelege escalation.To me, this sounds like a fairly onerous requirement for plugins. Based on the numerous published security advisories just around plugins not bothering with a permission check in the first place, this sounds like a fairly large hole. How could we mitigate that?
The difference is that much of that comes from bad (permissive) defaults. This would be opt-in, and with good documentation about security considerations, plugin maintainers will be given the tools to understand whether it makes sense to make this available, or not.