• 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

          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.

          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

          Ben Martin added a comment - - edited

          [Edit: Apologies for the upset tone. This comment was entered in the heat of disaster recovery.]
          Just a comment: This change caused a major downtime in my organization. We had scripts to rsync the build artifacts to a network location for release. This change caused the released files to be inaccessible to users. Worse, because we were in the same group as the Jenkins user, we were delayed diagnosing the issue.

          Blindly changing the umask used by the whole process seems like a very inappropriate response to a targeted issue.

          Until now, we had good luck with the Jenkins tip in production. We can not longer say that it is safe to do so.

          Ben Martin added a comment - - edited [Edit: Apologies for the upset tone. This comment was entered in the heat of disaster recovery.] Just a comment: This change caused a major downtime in my organization. We had scripts to rsync the build artifacts to a network location for release. This change caused the released files to be inaccessible to users. Worse, because we were in the same group as the Jenkins user, we were delayed diagnosing the issue. Blindly changing the umask used by the whole process seems like a very inappropriate response to a targeted issue. Until now, we had good luck with the Jenkins tip in production. We can not longer say that it is safe to do so.

          Jesse Glick added a comment -

          Copying artifacts directly out of $JENKINS_HOME is a marginal use case and the workaround was trivial (and there is also a configuration parameter to customize the behavior). The normal mechanism for accessing artifacts, using the REST API, is unaffected by this change.

          Jesse Glick added a comment - Copying artifacts directly out of $JENKINS_HOME is a marginal use case and the workaround was trivial (and there is also a configuration parameter to customize the behavior). The normal mechanism for accessing artifacts, using the REST API, is unaffected by this change.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          debian/debian/jenkins.default
          http://jenkins-ci.org/commit/jenkins/9c96f3dcca1784094f28ccd6df6abed1d229a1d4
          Log:
          [FIXED JENKINS-25065 JENKINS-24987]

          Based on the reaction to these issues and JENKINS-24514, I'm partially
          reverting the original change, and bringing the umask default back to
          022.

          The configurable option does enable the user to choose a different
          umask, so I think I can still claim that JENKINS-24514 is addressed.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html debian/debian/jenkins.default http://jenkins-ci.org/commit/jenkins/9c96f3dcca1784094f28ccd6df6abed1d229a1d4 Log: [FIXED JENKINS-25065 JENKINS-24987] Based on the reaction to these issues and JENKINS-24514 , I'm partially reverting the original change, and bringing the umask default back to 022. The configurable option does enable the user to choose a different umask, so I think I can still claim that JENKINS-24514 is addressed.

          Apologies for causing a regression! I assumed changes to /etc/default/jenkins would be relatively safe as I thought dpkg always ask to confirm changes.

          FWIW, I've used to do similar file copying from $JENKINS_HOME, so I don't consider this a fringe use case.

          I've switched back the default to 022 in the context of JENKINS-25065.

          Kohsuke Kawaguchi added a comment - Apologies for causing a regression! I assumed changes to /etc/default/jenkins would be relatively safe as I thought dpkg always ask to confirm changes. FWIW, I've used to do similar file copying from $JENKINS_HOME, so I don't consider this a fringe use case. I've switched back the default to 022 in the context of JENKINS-25065 .

          Ben Martin added a comment -

          Thanks!

          We ran into this behavior change in a fresh install. The ssd on our server died, so we re-ran the deployment scripts on the new disk. In hindsight, I should have protected myself by deploying a known version of Jenkins so we could separate upgrading Jenkins from server disaster recovery.

          I should have done my due diligence, but I'd gotten lucky in the past. Fortunately we were able to recover reasonably quickly.

          We use Jenkins for incremental build of a 1 GB, 1 Million LOC perl project. The incremental build is often only seconds vs ~30 minutes to run all our tests. Rsync only needs to copy the changed files. We release several times a day to several offices located in different countries, so the bandwidth savings really matter to us.

          Ben Martin added a comment - Thanks! We ran into this behavior change in a fresh install. The ssd on our server died, so we re-ran the deployment scripts on the new disk. In hindsight, I should have protected myself by deploying a known version of Jenkins so we could separate upgrading Jenkins from server disaster recovery. I should have done my due diligence, but I'd gotten lucky in the past. Fortunately we were able to recover reasonably quickly. We use Jenkins for incremental build of a 1 GB, 1 Million LOC perl project. The incremental build is often only seconds vs ~30 minutes to run all our tests. Rsync only needs to copy the changed files. We release several times a day to several offices located in different countries, so the bandwidth savings really matter to us.

          Soren Hansen added a comment -

          Debian policy says that package upgrades must take care of preserving user changes to conffiles. However, if there are no changes (i.e. /etc/default/jenkins hasn't been changed by a user after installing Jenkins), it will simply get overwritten by a new version of /etc/default/jenkins during upgrades.

          Soren Hansen added a comment - Debian policy says that package upgrades must take care of preserving user changes to conffiles. However, if there are no changes (i.e. /etc/default/jenkins hasn't been changed by a user after installing Jenkins), it will simply get overwritten by a new version of /etc/default/jenkins during upgrades.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          debian/jenkins.default
          debian/jenkins.init
          http://jenkins-ci.org/commit/packaging/b1067d4bcbc90a6ab7410cc583bce4351f5d150c
          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.

          Originally-From: jenkins-ci.org/commit/core/cf5a9b7c20dfab68247b1cbcf98ba28188475acc

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: debian/jenkins.default debian/jenkins.init http://jenkins-ci.org/commit/packaging/b1067d4bcbc90a6ab7410cc583bce4351f5d150c 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. Originally-From: jenkins-ci.org/commit/core/cf5a9b7c20dfab68247b1cbcf98ba28188475acc

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          debian/jenkins.default
          http://jenkins-ci.org/commit/packaging/9e97bed31ebd389bbca6889f8328c0b5725f26fc
          Log:
          [FIXED JENKINS-25065 JENKINS-24987]

          Based on the reaction to these issues and JENKINS-24514, I'm partially
          reverting the original change, and bringing the umask default back to
          022.

          The configurable option does enable the user to choose a different
          umask, so I think I can still claim that JENKINS-24514 is addressed.

          Originally-From: jenkins-ci.org/commit/core/9c96f3dcca1784094f28ccd6df6abed1d229a1d4

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: debian/jenkins.default http://jenkins-ci.org/commit/packaging/9e97bed31ebd389bbca6889f8328c0b5725f26fc Log: [FIXED JENKINS-25065 JENKINS-24987] Based on the reaction to these issues and JENKINS-24514 , I'm partially reverting the original change, and bringing the umask default back to 022. The configurable option does enable the user to choose a different umask, so I think I can still claim that JENKINS-24514 is addressed. Originally-From: jenkins-ci.org/commit/core/9c96f3dcca1784094f28ccd6df6abed1d229a1d4

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

              Created:
              Updated:
              Resolved: