• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Ubuntu Server 12.04 64 bits

      In the default Ubuntu install, several config files (all but identity.key and the secrets/ folder) are set world readable on the FS.

      This includes files containing user's credentials/passwords (users/admin/config.xml). Even if LDAP is in use instead of default authentication, the config.xml for Jenkins itself is world readable, disclosing the LDAP binding password to any other user of the system.

      In production environments where more than one person can access the system vía SSH or other means, or where more than one application lives on the same server, this could lead to credentials disclosure to unauthorized people. As a result, permissions of files containing sensitive information should be tightened to prevent other non-root users from reading them.

      Version tested is 1.514

          [JENKINS-24514] Weak Filesystem Permissions

          Adrian Bravo created issue -

          Jesse Glick added a comment -

          In general the administrator is expected to reject access to the Jenkins master computer, so I am not sure this even needs to be in the secret SECURITY project: there is no vulnerability to avoid disclosing. That said, a more restrictive default would probably be sensible. debian/debian/jenkins.postinst has

          # we don't do "chmod 750" so that the user can choose the pemission for g and o on their own
          chmod u+rwx /var/lib/jenkins /var/log/jenkins
          

          Now that could be reverted, essentially undoing https://github.com/jenkinsci/jenkins/commit/253fee372683a16328737acb3fc9507a3f2f10e3 though this might just irritate administrators who had permissions set up the way they did for a reason.

          Jesse Glick added a comment - In general the administrator is expected to reject access to the Jenkins master computer, so I am not sure this even needs to be in the secret SECURITY project: there is no vulnerability to avoid disclosing. That said, a more restrictive default would probably be sensible. debian/debian/jenkins.postinst has # we don't do "chmod 750" so that the user can choose the pemission for g and o on their own chmod u+rwx /var/lib/jenkins /var/log/jenkins Now that could be reverted, essentially undoing https://github.com/jenkinsci/jenkins/commit/253fee372683a16328737acb3fc9507a3f2f10e3 though this might just irritate administrators who had permissions set up the way they did for a reason.
          Kohsuke Kawaguchi made changes -
          Workflow Original: jira [ 149514 ] New: Security [ 152183 ]
          Kohsuke Kawaguchi made changes -
          Workflow Original: Security [ 152183 ] New: Security v1.1 [ 152277 ]
          Kohsuke Kawaguchi made changes -
          Workflow Original: Security v1.1 [ 152277 ] New: Security v1.2 [ 152372 ]

          I'm against doing massive chmod in postinst scripts. Anything that messes around with existing files has an inherently risk of breaking people's functioning installations. If we are to try to tighten up default file permissions, I think we should set umask to only affect newer files.

          The security architecture in Jenkins is such that every sensitive information in those configuration files (from LDAP passwords to user's API tokens) are encrypted by a key. So users/admin/config.xml readable by itself doesn't constitute a security vulnerability. The encryption keys that protect those files are stored in $JENKINS_HOME/secrets/*, and this directory is specifically created as 700.

          So I claim there's no current vulnerability.

          I'll keep this issue open to set umask value in packaging scripts.

          Kohsuke Kawaguchi added a comment - I'm against doing massive chmod in postinst scripts. Anything that messes around with existing files has an inherently risk of breaking people's functioning installations. If we are to try to tighten up default file permissions, I think we should set umask to only affect newer files. The security architecture in Jenkins is such that every sensitive information in those configuration files (from LDAP passwords to user's API tokens) are encrypted by a key. So users/admin/config.xml readable by itself doesn't constitute a security vulnerability. The encryption keys that protect those files are stored in $JENKINS_HOME/secrets/* , and this directory is specifically created as 700. So I claim there's no current vulnerability. I'll keep this issue open to set umask value in packaging scripts.
          Kohsuke Kawaguchi made changes -
          Component/s New: core [ 15593 ]
          Component/s Original: core [ 15738 ]
          Key Original: SECURITY-81 New: JENKINS-24514
          Project Original: Security Issues [ 10180 ] New: Jenkins [ 10172 ]
          Workflow Original: Security v1.2 [ 152372 ] New: JNJira [ 157500 ]

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          debian/debian/jenkins.default
          debian/debian/jenkins.init
          http://jenkins-ci.org/commit/jenkins/cf5a9b7c20dfab68247b1cbcf98ba28188475acc
          Log:
          [FIXED JENKINS-24514]

          Ubuntu (at least as of 12.04) has the default umask 022, which made some
          users nervous. Quoting its /etc/login.defs below, which explains its
          historical origin:

          UMASK is the default umask value for pam_umask and is used by
          useradd and newusers to set the mode of the new home directories.
          022 is the "historical" value in Debian for UMASK
          027, or even 077, could be considered better for privacy
          There is no One True Answer here : each sysadmin must make up his/her
          mind.

          It does seem to me that a bit more restrictive default is sensible,
          so this change introduces /etc/default/jenkins parameter that sets the
          default umask to 027 to prevent "others" from seeing files.

          Not that keys and other sensitive files are protected anyway, so it is
          not the case that the privacy of Jenkins data files have been vulnerable
          prior to this change.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html debian/debian/jenkins.default debian/debian/jenkins.init http://jenkins-ci.org/commit/jenkins/cf5a9b7c20dfab68247b1cbcf98ba28188475acc Log: [FIXED JENKINS-24514] Ubuntu (at least as of 12.04) has the default umask 022, which made some users nervous. Quoting its /etc/login.defs below, which explains its historical origin: UMASK is the default umask value for pam_umask and is used by useradd and newusers to set the mode of the new home directories. 022 is the "historical" value in Debian for UMASK 027, or even 077, could be considered better for privacy There is no One True Answer here : each sysadmin must make up his/her mind. It does seem to me that a bit more restrictive default is sensible, so this change introduces /etc/default/jenkins parameter that sets the default umask to 027 to prevent "others" from seeing files. Not that keys and other sensitive files are protected anyway, so it is not the case that the privacy of Jenkins data files have been vulnerable prior to this change.
          SCM/JIRA link daemon made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3659
          [FIXED JENKINS-24514] (Revision cf5a9b7c20dfab68247b1cbcf98ba28188475acc)

          Result = SUCCESS
          kohsuke : cf5a9b7c20dfab68247b1cbcf98ba28188475acc
          Files :

          • debian/debian/jenkins.default
          • debian/debian/jenkins.init
          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #3659 [FIXED JENKINS-24514] (Revision cf5a9b7c20dfab68247b1cbcf98ba28188475acc) Result = SUCCESS kohsuke : cf5a9b7c20dfab68247b1cbcf98ba28188475acc Files : debian/debian/jenkins.default debian/debian/jenkins.init changelog.html

            kohsuke Kohsuke Kawaguchi
            adrianbn Adrian Bravo
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: