I'll be reviewing this JEP from a security perspective over the next couple days.
On Wed, Jan 15, 2020 at 7:02 AM Oleg Nenashev <o.v.nenas...@gmail.com> wrote: > 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 > > > On Friday, December 27, 2019 at 8:30:30 PM UTC+1, Michael Cirioli wrote: >> >> 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* >> >> [image: permission_idea.png] >> >> >> >> >> On Monday, November 18, 2019 at 9:57:29 PM UTC-5, Michael Cirioli wrote: >>> >>> 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 >>> >>> -- > 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/7c9ba96b-1626-4af1-9964-bdad58bbb453%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/7c9ba96b-1626-4af1-9964-bdad58bbb453%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Matt Sicker Senior Software Engineer, CloudBees -- 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/CAEot4ow_k659Cbpo4N_7HgbmM%2B4pLeXU%3D9pegmkwu5ef5YrjkQ%40mail.gmail.com.
