Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-24513

Zero executors on master not well documented or enforced

    XMLWordPrintable

Details

    • 2.289.1, 2.286

    Description

      As described here:

      http://www.labofapenetrationtester.com/2014/08/script-execution-and-privilege-esc-jenkins.html

      A user with "configure" privileges can execute arbitrary code in the context of the application server running jenkins, and leverage this to bypass authentication and take full control of the jenkins server. This is only a problem because the security matrix seems to be designed to separate privileges, and the fact a user with "configure" privs for a single project can take over the whole server is non-obvious to administrators.

      Do you think this is something that constitutes a legitimate flaw to fix? Or more just something to be documented?

      Attachments

        Issue Links

          is duplicated by

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. JENKINS-49861 Disable master executors by default for Jenkins Essentials

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-33555 Provide option to disable master build executors while starting service

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved
          is related to

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-30749 Jenkins should be secure out of the box by default

          • Critical - Crashes, loss of data, severe memory leak.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-46652 Authorize Project blocks Pipeline Jobs when Computer/Build for master is lacking

          • Major - Major loss of function.
          • Resolved
          relates to

          Task - A task that needs to be done. JENKINS-22949 QueueItemAuthenticator fallback behavior cleanup

          • Major - Major loss of function.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-56617 Node-based security is ignored with pipelines

          • Major - Major loss of function.
          • Resolved
          links to

          Web Link CloudBees Internal OSS-2267

          Web Link jenkins PR 3919

          Activity

            Ascending order - Click to sort in descending order
            View 9 older comments
            jglick Jesse Glick added a comment -

            danielbeck notes that flyweight Pipeline tasks are also currently checked for Computer.BUILD on master, which makes no sense.

            jglick Jesse Glick added a comment - danielbeck notes that flyweight Pipeline tasks are also currently checked for Computer.BUILD on master, which makes no sense.
            danielbeck Daniel Beck added a comment - - edited

            I got started on an admin monitor for Access Control for Builds.

            The problem I ran into was determining when to show it – on instances where everyone is an admin anyway, it's pointless.

            My first idea was a RunListener that checks its causes for a UserIdCause, and if that is not an admin, to trigger the admin monitor. But that seems too narrow of a condition, and we probably want to err on the side of showing it too often rather than too rarely.

            Perhaps it's good enough to check for the selected authorization strategy, and if it's not one of the three or so with clear privilege separation (and perhaps if there's at least two users), show it.

            danielbeck Daniel Beck added a comment - - edited I got started on an admin monitor for Access Control for Builds . The problem I ran into was determining when to show it – on instances where everyone is an admin anyway, it's pointless. My first idea was a  RunListener that checks its causes for a UserIdCause, and if that is not an admin, to trigger the admin monitor. But that seems too narrow of a condition, and we probably want to err on the side of showing it too often rather than too rarely. Perhaps it's good enough to check for the selected authorization strategy, and if it's not one of the three or so with clear privilege separation (and perhaps if there's at least two users), show it.
            oleg_nenashev Oleg Nenashev added a comment -

            danielbeck's patches have been integrated to 2.168. Is it enough to close the issue?

            oleg_nenashev Oleg Nenashev added a comment - danielbeck 's patches have been integrated to 2.168. Is it enough to close the issue?
            danielbeck Daniel Beck added a comment -

            Unsure. This is probably more of an epic, and I did it a disservice by referencing it directly for a specific change.

            danielbeck Daniel Beck added a comment - Unsure. This is probably more of an epic, and I did it a disservice by referencing it directly for a specific change.
            wfollonier Wadeck Follonier added a comment -

            With https://github.com/jenkinsci/jenkins/pull/5337, I think this ticket could be considered as done. If not, please re-open it

            Released in jenkins-2.289.1+ and jenkins-2.286+

            wfollonier Wadeck Follonier added a comment - With https://github.com/jenkinsci/jenkins/pull/5337 , I think this ticket could be considered as done. If not, please re-open it Released in jenkins-2.289.1+ and jenkins-2.286+

            People

              Unassigned Unassigned
              dfj David Jorm
              Votes:
              1 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: