Proposal: Implementing sensible fine grained permissions to allow an administer to securely delegate some aspects of jenkins configuration

[Michael Cirioli]

Dear Everyone,

Myself (https://github.com/mikecirioli), Angelique Jard (https://github.com/aHenryJard), and Esther Feijoo (https://github.com/EstherAF) would like to offer a proposed JEP (currently, still a draft) focused on creating a more sensible set of fine-grained permissions for supporting Jenkins administrators who would like to delegate the management of certain aspects of a Jenkins instance in a secure manner.

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.

The WIP JEP draft may be found at https://github.com/jenkinsci/jep/pull/249 , this will continue to evolve over the coming days.

WIP implementation prototype can be found at https://github.com/mikecirioli/jenkins/tree/FGP (along with continuing work via PRs at https://github.com/mikecirioli/jenkins/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc )

thanks, we look forward to discussion and feedback about this proposal!

-mike cirioli

[Oleg Nenashev]

IMHO it should be aligned with the read-only administrator permissions being implemented by Tim Jacomb.

It does not have to be in the same JEP, but IMHO it is something to consider taking the timing.

BR, Oleg

[Jesse Glick]

On Mon, Nov 18, 2019 at 9:57 PM Michael Cirioli <mcir...@cloudbees.com> wrote:
> WIP implementation prototype can be found at https://github.com/mikecirioli/jenkins/tree/FGP

Would you mind filing this as a draft PR against jenkinsci/jenkins? While

https://github.com/jenkinsci/jenkins/compare/master...mikecirioli:FGP

can be used to _view_ the prototype implementation, there is otherwise
no way to _comment_ on it on a line-by-line basis. (General concerns
belong in the JEP.)

[Angélique Jard]

Hello there :)

I will create a draft PR today or tomorrow that integrate some feedback on the JEP like the name of the new permission "Jenkins.CONFIGURE", and remove the code related to deprecation to be more focused in this feature.

I think that I will also create a JIRA to be able to track all of this, and link the draft PR to a Jira number.

I will kept you informed as I progress on this topic.

[Michael Cirioli]

Sounds perfect, thank you Angelique!

Leaving Amsterdam and headed to Zurich this morning!

--
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.

[Daniel Beck]

On Tue, Nov 19, 2019 at 3:57 AM Michael Cirioli <mcir...@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.

[Angélique Jard]

Some update, I created a Jira to use it in PR and code, the draft PR is ready here https://github.com/jenkinsci/jenkins/pull/4374, tell me if I should add some label on it.
I also updated the link in the JEP PR, so every links should be up to date everywhere. The Jep still need some update, for example on the relation between READ and CONFIGURE.

For all the plugin configuration it will be a interesting place to allow some CONFIGURE permission, like updating some plugin from trusted sources. But it seems to be a topic by itself, so right now it's easier to leave that to ADMINISTER.

In parallel we will have a look at the read-only feature, and start the deprecation and replacement by ADMINISTER of 3 permissions(RUN_SCRIPTS, UPLOAD_PLUGINS, and CONFIGURE_UPDATECENTER) in a other PR.

Thank you for your feedback :)

[James Nord]

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.)

IMO that should be another Permission (and has been discussed internally as a follow up should this JEP be successful)
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).

At the same time just because you can configure the system message does not mean that you should be able to install new plugins.

/James

[Jesse Glick]

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?

[James Nord]

On Monday, November 25, 2019 at 8:43:07 PM UTC, Jesse Glick wrote:

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.

The point is to make the permissions fine grained enough that you can delegate this if you choose to.  most small setups will just use Administer so its moot, but large enterprises do want this.

some explicitly do not want the users to be able to install plugins (and if you are using the OSS update center and our plugin hosting means that if you allow a user to install any plugin (they can write one and get it hosted pretty easily) then you are allowing them to escallate to Administer pretty easily which is the complete point of Configure (you should not be able to).

its only ever safe to allow a Configure user to install / plugins if you own and vet the update center that your jenkins is using

 

> 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?

You are arguning that install plugins should be configure.  But not the other way around.  WHilst you could make Configure impliedby InstallPlugin there is no need to.  let that be the administrators choice - there are many impliedBy permissions that do not make sense (e.g. replay)

[James Nord]

sorry hit send to soon 

> 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?

You just answered the question.

" if you have this curated update center " - most people probably don't have this yet want to allow some level of configuration delegation.  You can make a fine grained permission into a coarser scheme but you can not effectivley break a coarse permission into finer ones (as the whole RUN_SCRIPTS / Administer shows)

[Jesse Glick]

I think it would be helpful for the JEP to have a lot more color in
the Motivation section. From the three short paragraphs given there it
is hard to tell what the real use cases for this change are. You are
saying something about a “large enterprise”, but

· Who typically is going to be granted `CONFIGURE` without
`ADMINISTER`, and who `ADMINISTER`? What would their job roles be
called?
· What are the archetypal things you would want to “configure” that
cannot be accomplished via Pipeline-as-code and which today are
available only with full administer privilege?
· What is the threat model of the “administrator”—intruders?
Disgruntled ex-employees? Accidental system destruction? Lazy
shortcuts by well-meaning developers?

> You can make a fine grained permission into a coarser scheme

You _could_, though for the most part Jenkins does not do so. Setting
aside global-scope permissions, there are a ton of confusing and
overly detailed permissions at other scopes today, all of which are
exposed in the common authorization strategies. This is basically
punting on real product design and just expecting the administrator to
assemble a meaningful high-level role on their own or by copying
examples. Most other systems I have used offer just a very short list
of comprehensible roles (e.g.: owner, writer, reader). Jenkins does
have the `impliedBy` system, so you can at least grant `ADMINISTER`
easily, though the UX is poor.

> you cannot effectively break a coarse permission into finer ones (as the whole RUN_SCRIPTS / Administer shows)

Indeed you cannot, though `RUN_SCRIPTS` vs. `ADMINISTER` was not a
good example of this—rather it was a case of the `impliesBy`
relationship between these two permissions being nonsensical.

[Michael Cirioli]

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

[Oleg Nenashev]

Just to bump this discussion, the JEP draft was published as https://github.com/jenkinsci/jep/tree/master/jep/223

Any feedback would be appreciated, there were changes since the last post in this thread

Best regards,

Oleg Nenashev

[Matt Sicker]

I'll be reviewing this JEP from a security perspective over the next couple days.

--
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.

--

Matt Sicker
Senior Software Engineer, CloudBees

[Matt Sicker]

Alright, I have some immediate concerns about the following aspects:

Plugins that contribute to the settings on on the Configure Jenkins page should carefully consider if allowing a user with only Jenkins.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?

[Daniel Beck]

On Wed, Jan 15, 2020 at 9:00 PM Matt Sicker <msi...@cloudbees.com> wrote:

Plugins that contribute to the settings on on the Configure Jenkins page should carefully consider if allowing a user with only Jenkins.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.

[Matt Sicker]

That would assuage my concerns significantly.

> --
> 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/CAMo7PtL5X07BBvtorwR5t8%3DO%3D8mHdGkkX79YqKYrMixoF7yLrw%40mail.gmail.com.