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

Seperate Permission for People View to close Security Hole with AD Plugin

    • 2.452

      Even when choosing the most restricted user rights (Role Plugin: Global Role only 1 Read), it is possible for every user to view the Jenkins User Id AND the name of the user (see screenshots).
      Working with an Active Directory for authentication, this means its possible for everybody to get the user names from AD AND the common names (Security Hole with AD Plugin?).

      Goal: create a Permission to allow specific People/Roles to see this User Account info and deny it to all others.

          [JENKINS-18884] Seperate Permission for People View to close Security Hole with AD Plugin

          Daniel Beck added a comment -

          Without permission to view people, other views that can also be used to list people known to Jenkins should be restricted as well, like 'Changes' (remove author information?).

          Maybe even information such as the field about who created a slave? Who started a build?

          There's little there can be done for change lists sent via email-ext though. Other plugins might also provide ways to circumvent restrictions.

          Daniel Beck added a comment - Without permission to view people, other views that can also be used to list people known to Jenkins should be restricted as well, like 'Changes' (remove author information?). Maybe even information such as the field about who created a slave? Who started a build? There's little there can be done for change lists sent via email-ext though. Other plugins might also provide ways to circumvent restrictions.

          ikedam added a comment -

          @danielbeck
          I'm afraid you completely misunderstand this issue.

          1. The severity is completely different that all users in Jenkins are visible and that some of users in a project is visible.
          2. Changelogs can be restrict to open only to users related to that project by using Matrix Authorization Strategy Plugin. This issue is that there is no way to restrict access to "People" view.
          3. Even though there are other security issues in Jenkins, it cannot be a reason to leave this issue.
          4. Even though there are plugins with security issues, it cannot be a reason for Jenkins not to care security.

          It is not reasonable to force users change their existing security policy only in order to introduce Jenkins.

          Of course, other problems you pointed should not be left.
          They should be considered to fix if someone cannot stand with them.

          ikedam added a comment - @danielbeck I'm afraid you completely misunderstand this issue. 1. The severity is completely different that all users in Jenkins are visible and that some of users in a project is visible. 2. Changelogs can be restrict to open only to users related to that project by using Matrix Authorization Strategy Plugin. This issue is that there is no way to restrict access to "People" view. 3. Even though there are other security issues in Jenkins, it cannot be a reason to leave this issue. 4. Even though there are plugins with security issues, it cannot be a reason for Jenkins not to care security. It is not reasonable to force users change their existing security policy only in order to introduce Jenkins. Of course, other problems you pointed should not be left. They should be considered to fix if someone cannot stand with them.

          ikedam added a comment - - edited

          Notes for customization:

          • Links to people list (/asynchPeople, /people) are available at:
            • core/src/main/resources/hudson/model/User/sidepanel.jelly
            • core/src/main/resources/hudson/model/View/AsynchPeople/index.jelly
            • core/src/main/resources/hudson/model/View/People/index.jelly
            • core/src/main/resources/hudson/model/View/sidepanel.jelly
            • core/src/main/resources/hudson/security/HudsonPrivateSecurityRealm/index.jelly (in blurb)
          • Methods providing people list to views are:
            • jenkins.model.Jenkins#getAsynchPeople()
            • jenkins.model.Jenkins#getPeople()
            • hudson.model.View#getAsynchPeople()
            • hudson.model.View#getPeople()
          • Models of people are:
            • hudson.model.View.People
            • hudson.model.View.AsynchPeople (subclass of jenkins.util.ProgressiveRendering)

          ikedam added a comment - - edited Notes for customization: Links to people list (/asynchPeople, /people) are available at: core/src/main/resources/hudson/model/User/sidepanel.jelly core/src/main/resources/hudson/model/View/AsynchPeople/index.jelly core/src/main/resources/hudson/model/View/People/index.jelly core/src/main/resources/hudson/model/View/sidepanel.jelly core/src/main/resources/hudson/security/HudsonPrivateSecurityRealm/index.jelly (in blurb) Methods providing people list to views are: jenkins.model.Jenkins#getAsynchPeople() jenkins.model.Jenkins#getPeople() hudson.model.View#getAsynchPeople() hudson.model.View#getPeople() Models of people are: hudson.model.View.People hudson.model.View.AsynchPeople (subclass of jenkins.util.ProgressiveRendering )

          Daniel Beck added a comment -

          Possible workaround: Hide Jenkins behind a reverse proxy (e.g. Apache). Configure it to listen only on the 127.0.0.1 interface (--httpListenAddress=127.0.0.1). Forbid access to people/asynchPeople URLs. Those links will then result in 403 Forbidden.

          Sample Apache httpd.conf excerpt, assuming reverse proxy and Jenkins are running on the same host, Jenkins on port 8080, Apache on port 80:

          <VirtualHost *:80>
                  RewriteEngine On
                  ServerName jenkins.example.org # change to actual server name
                  RewriteRule /asynchPeople/ - [F]
                  RewriteRule /people/ - [F]
                  ProxyPass         /  http://localhost:8080/
                  ProxyPassReverse  /  http://localhost:8080/
                  ProxyRequests     Off
          </VirtualHost>
          

          Of course, this simple pattern will prohibit access to e.g. the job named 'people' as well. Haven't tested this with all possible Jenkins URLs, making sure it works for those is left as an exercise to the reader

          This should keep at least most of the users out, even if it's likely not a 100% solution.

          Daniel Beck added a comment - Possible workaround: Hide Jenkins behind a reverse proxy (e.g. Apache). Configure it to listen only on the 127.0.0.1 interface ( --httpListenAddress=127.0.0.1 ). Forbid access to people/asynchPeople URLs. Those links will then result in 403 Forbidden. Sample Apache httpd.conf excerpt, assuming reverse proxy and Jenkins are running on the same host, Jenkins on port 8080, Apache on port 80: <VirtualHost *:80> RewriteEngine On ServerName jenkins.example.org # change to actual server name RewriteRule /asynchPeople/ - [F] RewriteRule /people/ - [F] ProxyPass / http: //localhost:8080/ ProxyPassReverse / http: //localhost:8080/ ProxyRequests Off </VirtualHost> Of course, this simple pattern will prohibit access to e.g. the job named 'people' as well. Haven't tested this with all possible Jenkins URLs, making sure it works for those is left as an exercise to the reader This should keep at least most of the users out, even if it's likely not a 100% solution.

          ikedam added a comment -

          Send a pull request.
          https://github.com/jenkinsci/jenkins/pull/1094

          Not created a new permission, but added configuration that People page requires READ permission or ADMINISTER permission.

          ikedam added a comment - Send a pull request. https://github.com/jenkinsci/jenkins/pull/1094 Not created a new permission, but added configuration that People page requires READ permission or ADMINISTER permission.

          ikedam added a comment -

          Another approach.
          https://github.com/jenkinsci/jenkins/pull/1094

          From the beginning, People page does not need to list ALL users in Jenkins, does it?

          ikedam added a comment - Another approach. https://github.com/jenkinsci/jenkins/pull/1094 From the beginning, People page does not need to list ALL users in Jenkins, does it?

          This is a serious security breach - so - not understand why this defect is fixing so long time.

          Konstantin Trunin added a comment - This is a serious security breach - so - not understand why this defect is fixing so long time.

          Maciej M added a comment -

          This issue is really blocking us from switching to Jenkins. Is there any forecast when this could be fixed?

          Maciej M added a comment - This issue is really blocking us from switching to Jenkins. Is there any forecast when this could be fixed?

          Kothandaraman added a comment -

          Is out there any way to disable "people" link on the Jenkins Dashboard page ?

          Kothandaraman added a comment - Is out there any way to disable "people" link on the Jenkins Dashboard page ?

          Created at 2013-07-23 10:03 Are you serious? What is the chance this security hole will be resolved this month? 

          Vladimír Čamaj added a comment - Created at 2013-07-23 10:03 Are you serious? What is the chance this security hole will be resolved this month? 

          Oleg Nenashev added a comment -

          vladimir81

          Please consider me as messenger here. First of all,  if this is a security issue from your point of view, please report it according to https://jenkins.io/security/#reporting-vulnerabilities .It is currently considered as a Security Hardening by the Jenkins security team (see the labels). Read as "request for enhancement". If you have additional data which may alter this decision, please report it to the security team. 

          Everybody is also welcome to take over https://github.com/jenkinsci/jenkins/pull/1102 from ikedam and to get it over the line.

          P.S: Personally I would love to see this fix integrated, and I consider it as important change to do. I am happy to help with reviews and with getting this change delivered, but I do not plan to work on this issue on my own.

           

          Oleg Nenashev added a comment - vladimir81 Please consider me as messenger here. First of all,  if this is a security issue from your point of view, please report it according to  https://jenkins.io/security/#reporting-vulnerabilities  .It is currently considered as a Security Hardening by the Jenkins security team (see the labels). Read as "request for enhancement". If you have additional data which may alter this decision, please report it to the security team.  Everybody is also welcome to take over  https://github.com/jenkinsci/jenkins/pull/1102  from ikedam and to get it over the line. P.S: Personally I would love to see this fix integrated, and I consider it as important change to do. I am happy to help with reviews and with getting this change delivered, but I do not plan to work on this issue on my own.  

          Exposing users like this violates various laws in some countries. A number of PRs have been submitted to fix this, but they keep getting closed.

          Who is responsible for jenkins security who can pick this up?

          Graham Leggett added a comment - Exposing users like this violates various laws in some countries. A number of PRs have been submitted to fix this, but they keep getting closed. Who is responsible for jenkins security who can pick this up?

          Daniel Beck added a comment -

          A number of PRs have been submitted to fix this, but they keep getting closed

          Could you link to those PRs? There are only two I'm aware of, from 2014, by the same author, and closed by their author when they lost interest, both linked above.

          Who is responsible for jenkins security who can pick this up?

          The Jenkins security team has no particular interest in this issue. We do not consider it to be a vulnerability. The current behavior is documented and access can be prevented by not granting Overall/Read permission. So while it may be inconvenient for your use case, it essentially "just" raises the bar who gets to have that permission in any particular organization.

          Daniel Beck added a comment - A number of PRs have been submitted to fix this, but they keep getting closed Could you link to those PRs? There are only two I'm aware of, from 2014, by the same author, and closed by their author when they lost interest, both linked above. Who is responsible for jenkins security who can pick this up? The Jenkins security team has no particular interest in this issue. We do not consider it to be a vulnerability. The current behavior is documented and access can be prevented by not granting Overall/Read permission. So while it may be inconvenient for your use case, it essentially "just" raises the bar who gets to have that permission in any particular organization.

          I create a new PR: https://github.com/jenkinsci/jenkins/pull/9052, still struggeling with the tests

          Martin Reinhardt added a comment - I create a new PR: https://github.com/jenkinsci/jenkins/pull/9052 , still struggeling with the tests

          Daniel Beck added a comment - - edited

          While not specifically what was requested here, 2.452 removes the People views from core. Therefore I'm closing this issue.

          Install https://plugins.jenkins.io/people-view/ to restore the feature if you need it. Unlike most features moved from core into a plugin, it's not bundled or an implicit dependency from other plugins. Note that it does not require additional permissions. It's intentionally the same feature as before, just provided through a plugin.

          Other plugins may implement other views on the same or similar data, possibly protected by a new permission.

          Daniel Beck added a comment - - edited While not specifically what was requested here, 2.452 removes the People views from core. Therefore I'm closing this issue. Install https://plugins.jenkins.io/people-view/ to restore the feature if you need it. Unlike most features moved from core into a plugin, it's not bundled or an implicit dependency from other plugins. Note that it does not require additional permissions. It's intentionally the same feature as before, just provided through a plugin. Other plugins may implement other views on the same or similar data, possibly protected by a new permission.

          Fred G added a comment -

          Thanks, Daniel, for removing the People views from core. This is a much anticipated and appreciated change!

          Fingers crossed that it will be part of the next LTS baseline!

          Fred G added a comment - Thanks, Daniel, for removing the People views from core. This is a much anticipated and appreciated change! Fingers crossed that it will be part of the next LTS baseline!

            danielbeck Daniel Beck
            night_shift Annabella Schmidt
            Votes:
            21 Vote for this issue
            Watchers:
            29 Start watching this issue

              Created:
              Updated:
              Resolved: