On Tue, Nov 19, 2019 at 3:57 AM Michael Cirioli <mciri...@cloudbees.com> wrote:
> > 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. > I am unaware of any public authorization strategy that cuts the implication from ADMINISTER to these other permissions (which we've dubbed 'dangerous'). It was always the other way around, with confused admins opening up their instance to security issues when granting non-admins Overall/RunScripts permission (and thereby access to /script). This is why matrix-auth and role-strategy haven't allowed configuring these permissions for years. So it's probably time we retired them. They're confusing and barely relevant. > 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). > *two thumbs up* > 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. > 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.) > 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. > About two years ago, we had to address a security vulnerability in Jenkins core: Users with Agent/Configure permission were able to configure the "Launch agent by running a command on master"… which is obviously not great, as it basically escalates Agent/Configure to Overall/RunScripts. I would expect that the configuration of clouds would be a prime candidate to make available to users with the new Overall/Configure permission. Do you have any thoughts on how to prevent similar situations there? For comparison, AFAIUI, tool configuration remains restricted because of the ability to download arbitrary zip files, or specify OS commands as tool locations; and any similarly extensible/nested configuration should have a similar risk. If a tool would not offer these specific installation methods, wouldn't it be considered safe to open up configuration to CONFIGURE_JENKINS? Anyway, I'm excited about this proposal. -- 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-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtJiEiVhHv_GX%3DUSOPo-_jPxN%2B6p_mcpPiCUeTmOiarYAw%40mail.gmail.com.
