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

          Activity

            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.

            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: