Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-10644

solr.in.sh installed by install script should not be world readable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.6, 7.0
    • Component/s: scripts and tools
    • Security Level: Public (Default Security Level. Issues are Public)
    • Labels:
      None

      Description

      Spinoff from SOLR-8440

      install_solr_service.sh installs solr.in.sh as world-readable but not solr user writable:

      -rw-r--r-- 1 root root 5968 Feb 15 14:55 /etc/default/solr.in.sh
      

      For better security, and ease for scripts to update solr.in.sh, this should change to:

      -rw-rw---- 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh
      
      1. SOLR-10644.patch
        1 kB
        Jan Høydahl
      2. SOLR-10644-reopen.patch
        1 kB
        Jan Høydahl

        Issue Links

          Activity

          Hide
          janhoy Jan Høydahl added a comment -

          I'm opting for owned by solr instead:

          -rw-rw---- 1 solr root 5968 Feb 15 14:55 /etc/default/solr.in.sh
          
          Show
          janhoy Jan Høydahl added a comment - I'm opting for owned by solr instead: -rw-rw---- 1 solr root 5968 Feb 15 14:55 /etc/default/solr.in.sh
          Hide
          janhoy Jan Høydahl added a comment -

          Patch

          Show
          janhoy Jan Høydahl added a comment - Patch
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit d59faafd895dfa71f7729530fe4e38a9d84e7c27 in lucene-solr's branch refs/heads/master from Jan Høydahl
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d59faaf ]

          SOLR-10644: solr.in.sh installed by install script should be writable by solr user

          Show
          jira-bot ASF subversion and git services added a comment - Commit d59faafd895dfa71f7729530fe4e38a9d84e7c27 in lucene-solr's branch refs/heads/master from Jan Høydahl [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d59faaf ] SOLR-10644 : solr.in.sh installed by install script should be writable by solr user
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit efed0277dd3fe9b7e81f260f4f2d4fc023eea50d in lucene-solr's branch refs/heads/branch_6x from Jan Høydahl
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=efed027 ]

          SOLR-10644: solr.in.sh installed by install script should be writable by solr user

          (cherry picked from commit d59faaf)

          Show
          jira-bot ASF subversion and git services added a comment - Commit efed0277dd3fe9b7e81f260f4f2d4fc023eea50d in lucene-solr's branch refs/heads/branch_6x from Jan Høydahl [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=efed027 ] SOLR-10644 : solr.in.sh installed by install script should be writable by solr user (cherry picked from commit d59faaf)
          Hide
          janhoy Jan Høydahl added a comment -

          Tested on Ubuntu. Committed.

          Show
          janhoy Jan Høydahl added a comment - Tested on Ubuntu. Committed.
          Hide
          hossman Hoss Man added a comment -

          wait ... what?

          FWIW: I'm -0 on the installer making solr.in.sh writable by any user other then the user running the installer (ie: "root").

          In general this seems like a really risky step that could make potential security holes in the future 10x worse then they would be otherwise. Example: imagine a hypothetical future security hole where a solr request handler allows writting to files on disk. if the filesystem permissions of solr.in.sh mean it's writable by the solr user running the webapp, now an attacker can influence the way the solr webapp is run on restart, opening up more holes.

          if the motivation here is to allow bin/solr ... subcommands to easily muck with solr.in.sh then the solution to that objective should be error checking and help messages instructing the user that those specific commands need to be run as root via {{sudo bin/solr ... }}

          In general, the places a service's effective UID should be able to write to should be VERY limited, and constrained tothe well known place where that service keeps it's "data" ... enabling apps with the ability to overwrite their configuration is a big red flag.

          Show
          hossman Hoss Man added a comment - wait ... what? FWIW: I'm -0 on the installer making solr.in.sh writable by any user other then the user running the installer (ie: "root"). In general this seems like a really risky step that could make potential security holes in the future 10x worse then they would be otherwise. Example: imagine a hypothetical future security hole where a solr request handler allows writting to files on disk. if the filesystem permissions of solr.in.sh mean it's writable by the solr user running the webapp, now an attacker can influence the way the solr webapp is run on restart, opening up more holes. if the motivation here is to allow bin/solr ... subcommands to easily muck with solr.in.sh then the solution to that objective should be error checking and help messages instructing the user that those specific commands need to be run as root via {{sudo bin/solr ... }} In general, the places a service's effective UID should be able to write to should be VERY limited, and constrained tothe well known place where that service keeps it's "data" ... enabling apps with the ability to overwrite their configuration is a big red flag.
          Hide
          janhoy Jan Høydahl added a comment -

          Good point. Let's keep it root owned. But can we make it "solr" readable without also being readable to the world (given that the file may contain passwords)? We could do:

          chown root:${SOLR_USER} "/etc/default/$SOLR_SERVICE.in.sh"
          chmod 0640 "/etc/default/$SOLR_SERVICE.in.sh"
          

          This would produce

          -rw-r----- 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh
          

          This will only work if the usergroup with same name is there, which I believe is default on Debian based systems at least...

          Show
          janhoy Jan Høydahl added a comment - Good point. Let's keep it root owned. But can we make it "solr" readable without also being readable to the world (given that the file may contain passwords)? We could do: chown root:${SOLR_USER} "/etc/default/$SOLR_SERVICE.in.sh" chmod 0640 "/etc/default/$SOLR_SERVICE.in.sh" This would produce -rw-r----- 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh This will only work if the usergroup with same name is there, which I believe is default on Debian based systems at least...
          Hide
          hossman Hoss Man added a comment -

          This would produce ...

          that seems fine by me.

          personally I don't see any downside to it being world readable – yes it may contain "passwords", but anyone with local access to the system who can read a world readable file can also read "ps" output and see any property from that file that might be passed to a running solr process.

          Show
          hossman Hoss Man added a comment - This would produce ... that seems fine by me. personally I don't see any downside to it being world readable – yes it may contain "passwords", but anyone with local access to the system who can read a world readable file can also read "ps" output and see any property from that file that might be passed to a running solr process.
          Hide
          janhoy Jan Høydahl added a comment -

          Reopening...

          That's why I opened SOLR-10646, to avoid putting at least basic auth pwd on the command line. But then it turns out that kerberos mode needs them...

          I know there are other efforts under way to secure other passwords better, so perhaps we'll at some point get rid of pws both in solr.in and in cmdline.

          An option someone proposed was to pass passwords through shell env variables but not as Java Option. That way it is not visible in ps, but Solr could still read the variable with System.getenv()... In that case it could make sense to have password in a o-rwx solr.in.sh file?

          Show
          janhoy Jan Høydahl added a comment - Reopening... That's why I opened SOLR-10646 , to avoid putting at least basic auth pwd on the command line. But then it turns out that kerberos mode needs them... I know there are other efforts under way to secure other passwords better, so perhaps we'll at some point get rid of pws both in solr.in and in cmdline. An option someone proposed was to pass passwords through shell env variables but not as Java Option. That way it is not visible in ps, but Solr could still read the variable with System.getenv() ... In that case it could make sense to have password in a o-rwx solr.in.sh file?
          Hide
          janhoy Jan Høydahl added a comment -

          Attaching proposed patch SOLR-10644-reopen.patch

          • solr.in.sh will be owned by root, readable by SOLR_USER but not by world
          • tested on Ubuntu, CentOS and OpenSuse
          • For OpenSuse, user-group was not created by default, so modified useradd command to create user-group -U and to place home-dir in /var/solr
            useradd --system -U -m --home-dir "$SOLR_VAR_DIR" "$SOLR_USER"
          • Did the same modifications for RedHat (tested on CentOS) for completeness
          Show
          janhoy Jan Høydahl added a comment - Attaching proposed patch SOLR-10644 -reopen.patch solr.in.sh will be owned by root, readable by SOLR_USER but not by world tested on Ubuntu, CentOS and OpenSuse For OpenSuse, user-group was not created by default, so modified useradd command to create user-group -U and to place home-dir in /var/solr useradd --system -U -m --home-dir "$SOLR_VAR_DIR" "$SOLR_USER" Did the same modifications for RedHat (tested on CentOS) for completeness
          Hide
          janhoy Jan Høydahl added a comment -

          Unless there are objections to the proposed SOLR-10644-reopen.patch, I'll commit that to master, branch_6x and branch_6_6 and resolve the issue.
          The alternative is to revert the original change for this issue and leave solr.in.sh world readable
          (Changed issue title)

          Show
          janhoy Jan Høydahl added a comment - Unless there are objections to the proposed SOLR-10644 -reopen.patch, I'll commit that to master, branch_6x and branch_6_6 and resolve the issue. The alternative is to revert the original change for this issue and leave solr.in.sh world readable (Changed issue title)
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 50a08042630c28fb2b85a05440dae170a46cbf49 in lucene-solr's branch refs/heads/master from Jan Høydahl
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=50a0804 ]

          SOLR-10644: Make solr.in.sh owned by root, readable to solr (group) but not world-readable

          Show
          jira-bot ASF subversion and git services added a comment - Commit 50a08042630c28fb2b85a05440dae170a46cbf49 in lucene-solr's branch refs/heads/master from Jan Høydahl [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=50a0804 ] SOLR-10644 : Make solr.in.sh owned by root, readable to solr (group) but not world-readable
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 45627d48f99ee014dda8f781befecfbd76669126 in lucene-solr's branch refs/heads/branch_6x from Jan Høydahl
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=45627d4 ]

          SOLR-10644: Make solr.in.sh owned by root, readable to solr (group) but not world-readable

          (cherry picked from commit 50a0804)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 45627d48f99ee014dda8f781befecfbd76669126 in lucene-solr's branch refs/heads/branch_6x from Jan Høydahl [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=45627d4 ] SOLR-10644 : Make solr.in.sh owned by root, readable to solr (group) but not world-readable (cherry picked from commit 50a0804)
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit a5597a98b5ea5f52c45b7fc55e31ec7e8633b907 in lucene-solr's branch refs/heads/branch_6_6 from Jan Høydahl
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a5597a9 ]

          SOLR-10644: Make solr.in.sh owned by root, readable to solr (group) but not world-readable

          (cherry picked from commit 50a0804)

          Show
          jira-bot ASF subversion and git services added a comment - Commit a5597a98b5ea5f52c45b7fc55e31ec7e8633b907 in lucene-solr's branch refs/heads/branch_6_6 from Jan Høydahl [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a5597a9 ] SOLR-10644 : Make solr.in.sh owned by root, readable to solr (group) but not world-readable (cherry picked from commit 50a0804)
          Hide
          janhoy Jan Høydahl added a comment -

          Closing again after adjustments

          Show
          janhoy Jan Høydahl added a comment - Closing again after adjustments

            People

            • Assignee:
              janhoy Jan Høydahl
              Reporter:
              janhoy Jan Høydahl
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development