Derby
  1. Derby
  2. DERBY-2196

Run standalone network server with security manager by default

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.3.1.4
    • Component/s: Network Server
    • Labels:
      None
    • Issue & fix info:
      Release Note Needed
    • Bug behavior facts:
      Security

      Description

      From an e-mail discussion:
      ... Derby should match the security provided by typical client server systems such as DB2, Oracle, etc. I
      think in this case system/database owners are trusting the database
      system to ensure that their system cannot be attacked. So maybe if Derby
      is booted as a standalone server with no security manager involved, it
      should install one with a default security policy. Thus allowing Derby
      to use Java security manager to manage system privileges but not
      requiring everyone to become familiar with them.

      http://mail-archives.apache.org/mod_mbox/db-derby-dev/200612.mbox/%3c4582FE67.7040308@apache.org%3e

      I imagine such a policy would allow any access to databases under derby.system.home and/or user.home.
      By standalone I mean the network server was started though the main() method (command line).

      1. secureServer.html
        25 kB
        Dag H. Wanvik
      2. secureServer.html
        24 kB
        Dag H. Wanvik
      3. secureServer.html
        23 kB
        Rick Hillegas
      4. secureServer.html
        23 kB
        Rick Hillegas
      5. releaseNote.html
        4 kB
        Rick Hillegas
      6. releaseNote.html
        4 kB
        Rick Hillegas
      7. releaseNote.html
        4 kB
        Rick Hillegas
      8. releaseNote.html
        4 kB
        Rick Hillegas
      9. secureServer.html
        23 kB
        Rick Hillegas
      10. secureServerReleaseNote.html
        5 kB
        Rick Hillegas
      11. secureServer.html
        23 kB
        Rick Hillegas
      12. secureServer.html
        21 kB
        Rick Hillegas
      13. derby-2196-10-renameOption-01.diff
        11 kB
        Rick Hillegas
      14. derby-2196-03-tests-01.diff
        23 kB
        Rick Hillegas
      15. derby-2196-02-install-01.diff
        25 kB
        Rick Hillegas
      16. derby-2196-01-print-03.diff
        4 kB
        Rick Hillegas
      17. secureServer.html
        21 kB
        Rick Hillegas
      18. derby-2196-01-print-02.diff
        8 kB
        Rick Hillegas
      19. derby-2196-01-print-01.diff
        8 kB
        Rick Hillegas
      20. secureServer.html
        18 kB
        Rick Hillegas
      21. secureServer.html
        17 kB
        Rick Hillegas
      22. secureServer.html
        15 kB
        Rick Hillegas
      23. secureServer.html
        14 kB
        Rick Hillegas
      24. secureServer.html
        13 kB
        Rick Hillegas

        Issue Links

          Activity

          Hide
          Dag H. Wanvik added a comment -

          fixed on more line in func spec.

          Show
          Dag H. Wanvik added a comment - fixed on more line in func spec.
          Hide
          Dag H. Wanvik added a comment -

          Updated func spec to reflect changes in DERBY-2963.

          Show
          Dag H. Wanvik added a comment - Updated func spec to reflect changes in DERBY-2963 .
          Hide
          Rick Hillegas added a comment -

          Correct a mis-statement in the Rejected Alternatives section of the previous rev.

          Show
          Rick Hillegas added a comment - Correct a mis-statement in the Rejected Alternatives section of the previous rev.
          Hide
          Rick Hillegas added a comment -

          Attaching new version of the functional spec. This reflects the following changes which were introduced during the last couple weeks:

          1) Authorization is no longer required when the server installs a security manager

          2) The default SocketPermission has been changed to not have a wildcarded port spec. In addition, the SocketPermission now references a new system property derby.security.host.

          Note that the spec may change further based on the resolution of DERBY-2874.

          Show
          Rick Hillegas added a comment - Attaching new version of the functional spec. This reflects the following changes which were introduced during the last couple weeks: 1) Authorization is no longer required when the server installs a security manager 2) The default SocketPermission has been changed to not have a wildcarded port spec. In addition, the SocketPermission now references a new system property derby.security.host. Note that the spec may change further based on the resolution of DERBY-2874 .
          Hide
          Rick Hillegas added a comment -

          Attach new version of the release note. This reflects the work on derby-2757. This version of the release note urges the user to enable user authentication and to customize the default policy file as described in the user guides.

          Show
          Rick Hillegas added a comment - Attach new version of the release note. This reflects the work on derby-2757. This version of the release note urges the user to enable user authentication and to customize the default policy file as described in the user guides.
          Hide
          Rick Hillegas added a comment -

          Updating the release note to quote a new version of the network server error message which was checked in to address DERBY-2433.

          Show
          Rick Hillegas added a comment - Updating the release note to quote a new version of the network server error message which was checked in to address DERBY-2433 .
          Hide
          Myrna van Lunteren added a comment -

          Can this issue be resolved/closed?

          Show
          Myrna van Lunteren added a comment - Can this issue be resolved/closed?
          Hide
          Rick Hillegas added a comment -

          Attach a second version of the release note in order to verfiy that the Release Note Generator picks up the latest version.

          Show
          Rick Hillegas added a comment - Attach a second version of the release note in order to verfiy that the Release Note Generator picks up the latest version.
          Hide
          Rick Hillegas added a comment -

          Attaching releaseNote.html conforming to the new format.

          Show
          Rick Hillegas added a comment - Attaching releaseNote.html conforming to the new format.
          Hide
          Rick Hillegas added a comment -

          Attaching new rev of the functional spec for this feature. This rev makes the following changes:

          1) renames the policy-reloading system procedure

          2) separates the Template policy from the Basic policy

          Show
          Rick Hillegas added a comment - Attaching new rev of the functional spec for this feature. This rev makes the following changes: 1) renames the policy-reloading system procedure 2) separates the Template policy from the Basic policy
          Hide
          Rick Hillegas added a comment -

          Attaching 2 release notes in the file secureServerReleaseNote.html. These notes describe how to recover from the upgrade incompatibilities introduced by the secure server work.

          Show
          Rick Hillegas added a comment - Attaching 2 release notes in the file secureServerReleaseNote.html. These notes describe how to recover from the upgrade incompatibilities introduced by the secure server work.
          Hide
          Rick Hillegas added a comment -

          What should be do about the network startup scripts? Now if you run startNetworkServer, the server fails to come up. It exits, complaining that it can't install a security manager until you specify how you want to authenticate users. Here are some bad options:

          1) Let the startup script continue to fail.

          2) Add the -noSecurityManager option to the java command. This seems like a bad example to set in a template script.

          3) Add some more system properties so that the server comes up with BUILTIN authentication and some default system administrator's username and password.

          I would appreciate the community's guidance here.

          Show
          Rick Hillegas added a comment - What should be do about the network startup scripts? Now if you run startNetworkServer, the server fails to come up. It exits, complaining that it can't install a security manager until you specify how you want to authenticate users. Here are some bad options: 1) Let the startup script continue to fail. 2) Add the -noSecurityManager option to the java command. This seems like a bad example to set in a template script. 3) Add some more system properties so that the server comes up with BUILTIN authentication and some default system administrator's username and password. I would appreciate the community's guidance here.
          Hide
          Rick Hillegas added a comment -

          Attaching rev 8 of the functional spec. This improves the Upgrade section, folding in more exact descriptions of incompatibilities. Those descriptions evolved yesterday via a discussion on derby-dev and edits to the 10.3 wiki page.

          Show
          Rick Hillegas added a comment - Attaching rev 8 of the functional spec. This improves the Upgrade section, folding in more exact descriptions of incompatibilities. Those descriptions evolved yesterday via a discussion on derby-dev and edits to the 10.3 wiki page.
          Hide
          Rick Hillegas added a comment -

          Attaching derby-2196-10-renameOption-01.diff, which renames the -unsecure option to be -noSecurityManager as Bernt and Andrew requested. Committed at subversion revision 510549. The unit tests ran cleanly for me. I think that the compatibility tests should run cleanly too although I haven't been able to run them because I don't have the 10.0.2.1 jars anymore.

          Also attaching rev 7 of the functional spec. This incorporates two changes:

          1) The change from -unsecure to -noSecurityManager

          2) The change to the Basic policy, replacing the two codebase properties with a single property which points to the directory of Derby jars

          Show
          Rick Hillegas added a comment - Attaching derby-2196-10-renameOption-01.diff, which renames the -unsecure option to be -noSecurityManager as Bernt and Andrew requested. Committed at subversion revision 510549. The unit tests ran cleanly for me. I think that the compatibility tests should run cleanly too although I haven't been able to run them because I don't have the 10.0.2.1 jars anymore. Also attaching rev 7 of the functional spec. This incorporates two changes: 1) The change from -unsecure to -noSecurityManager 2) The change to the Basic policy, replacing the two codebase properties with a single property which points to the directory of Derby jars
          Hide
          Bernt M. Johnsen added a comment -

          The last paragraph in Andrew's last comment is DERBY-2363 (which I think is a good idea as long as it is the client thet is negtiable on this, and not the server). But I do also think that developers also need fingertip control in some environments.

          BTW: The flags for encryption on the wire (read SSL) as I plan to implement them is found in the funcspec in DERBY-2356 (there are some changes from DERBY-2108). Seems that we need some alignment here, so please comment.... Note also, that if the server is going to run with SSL by default, the user will have to generate a public/private key pair before starting the server (and no, I don't think supplying the key pair with the derby distribution is a good idea since all an adversary needs to do to break the encryption then, is to get the private key from the Derby download site).

          Show
          Bernt M. Johnsen added a comment - The last paragraph in Andrew's last comment is DERBY-2363 (which I think is a good idea as long as it is the client thet is negtiable on this, and not the server). But I do also think that developers also need fingertip control in some environments. BTW: The flags for encryption on the wire (read SSL) as I plan to implement them is found in the funcspec in DERBY-2356 (there are some changes from DERBY-2108 ). Seems that we need some alignment here, so please comment.... Note also, that if the server is going to run with SSL by default, the user will have to generate a public/private key pair before starting the server (and no, I don't think supplying the key pair with the derby distribution is a good idea since all an adversary needs to do to break the encryption then, is to get the private key from the Derby download site).
          Hide
          Andrew McIntyre added a comment -

          So, after looking into the security mechanisms a little deeper, it turns out that the issue was in fact already discussed, and JIRA issues filed for the problems blocking the use of encryption as the default. See DERBY-926, DERBY-1517 and DERBY-1755 for the current issues with username/password encryption, as well as the extensive discussions in DERBY-528 and DERBY-928.

          Assuming the issues listed above can be fixed, I don't see a need for having a separate noWireEncryption flag, but simply always using an encrypted connection mechanism. Not sure what the expected client behavior would be for new client / old server if the client can't negotiate an encrypted protocol. Failing down to an unencrypted security mechanism would probably not be desirable from a secure-out-of-the-box standpoint.

          Show
          Andrew McIntyre added a comment - So, after looking into the security mechanisms a little deeper, it turns out that the issue was in fact already discussed, and JIRA issues filed for the problems blocking the use of encryption as the default. See DERBY-926 , DERBY-1517 and DERBY-1755 for the current issues with username/password encryption, as well as the extensive discussions in DERBY-528 and DERBY-928 . Assuming the issues listed above can be fixed, I don't see a need for having a separate noWireEncryption flag, but simply always using an encrypted connection mechanism. Not sure what the expected client behavior would be for new client / old server if the client can't negotiate an encrypted protocol. Failing down to an unencrypted security mechanism would probably not be desirable from a secure-out-of-the-box standpoint.
          Hide
          Rick Hillegas added a comment -

          Thanks, Andrew and Bernt, for the additional feedback. I would like to continue the discussion from Andrew's post:

          I think it would be reasonable for the network server to require username/password encryption on the wire. However, I'm not sure of the implications of this for existing apps and I would appreciate more discussion by the community. I also think that it is a separate JIRA.

          But let's suppose that we decide that a secure-by-default server boots up requiring username/password encryption also. These appear to be the two models on the table:

          1) In this scenario, "-unsecure" is a generic disabling flag with more or less the following meaning: "Let my legacy apps run unmodified." That is, the "-unsecure" flag overrides the booted server's impulse both to install a Java Security Manager and require wire encryption.

          2) In this scenario, there are separate disabling startup flags, "-noSecurityManager" and "noWireEncryption".

          Which of these seems better?

          Show
          Rick Hillegas added a comment - Thanks, Andrew and Bernt, for the additional feedback. I would like to continue the discussion from Andrew's post: I think it would be reasonable for the network server to require username/password encryption on the wire. However, I'm not sure of the implications of this for existing apps and I would appreciate more discussion by the community. I also think that it is a separate JIRA. But let's suppose that we decide that a secure-by-default server boots up requiring username/password encryption also. These appear to be the two models on the table: 1) In this scenario, "-unsecure" is a generic disabling flag with more or less the following meaning: "Let my legacy apps run unmodified." That is, the "-unsecure" flag overrides the booted server's impulse both to install a Java Security Manager and require wire encryption. 2) In this scenario, there are separate disabling startup flags, "-noSecurityManager" and "noWireEncryption". Which of these seems better?
          Hide
          Bernt M. Johnsen added a comment -

          Rick Hillegas [20/Feb/07 06:54 AM]:
          > [...] I'm not a big fan of introducing a lot of flags to control
          > individual security features.

          I see the need for simplicity, because security is rather
          complex. But, we can't have one unsecure mode with everything turned
          off and another with everything turned on. Every security feature has
          some penalty like performance degradation (like SSL or running with
          security manager) or administrative complexity (getting the policy
          file right or certificate distribution for SSL peer authentication)
          and the user/application programmer will have to do a trade-off
          between e.g. performance and security based on his/hers specific
          needs.

          Show
          Bernt M. Johnsen added a comment - Rick Hillegas [20/Feb/07 06:54 AM] : > [...] I'm not a big fan of introducing a lot of flags to control > individual security features. I see the need for simplicity, because security is rather complex. But, we can't have one unsecure mode with everything turned off and another with everything turned on. Every security feature has some penalty like performance degradation (like SSL or running with security manager) or administrative complexity (getting the policy file right or certificate distribution for SSL peer authentication) and the user/application programmer will have to do a trade-off between e.g. performance and security based on his/hers specific needs.
          Hide
          Andrew McIntyre added a comment -

          I'm agreeing with Bernt here. Also, what none of the discussions of client/server seem to have taken into account is the client security mechanism for encrypting username and password over the wire. Unless I'm mistaken, the default is still currently clear text and derby.drda.securityMechanism remains undocumented. So unless that default is changed, calling the option --unsecure is a little misleading when the username and password go out over the wire as clear text. SSL will certainly help, but not if it is not enabled by default. I have a vague recollection of there being discussions to change the default security mechanism to the strong substitute, USRSSBPWD, once that method was introduced, but I'm not sure where it ended up.

          Show
          Andrew McIntyre added a comment - I'm agreeing with Bernt here. Also, what none of the discussions of client/server seem to have taken into account is the client security mechanism for encrypting username and password over the wire. Unless I'm mistaken, the default is still currently clear text and derby.drda.securityMechanism remains undocumented. So unless that default is changed, calling the option --unsecure is a little misleading when the username and password go out over the wire as clear text. SSL will certainly help, but not if it is not enabled by default. I have a vague recollection of there being discussions to change the default security mechanism to the strong substitute, USRSSBPWD, once that method was introduced, but I'm not sure where it ended up.
          Hide
          Rick Hillegas added a comment -

          Committed derby-2196-03-tests-01.diff at subversion revision 509693.

          Show
          Rick Hillegas added a comment - Committed derby-2196-03-tests-01.diff at subversion revision 509693.
          Hide
          Rick Hillegas added a comment -

          HI Bernt. Thanks for the feedback on the name of the override flag. I agree that "secure-by-default" means, at best, "has no security holes that we understand". One thing that I like about "unsecure" as a flag name is this: it allows the flag to control other security mechanisms besides the installation of a Java security manager. I'm not a big fan of introducing a lot of flags to control individual security features. I think that the discussion on DERBY-2264 gives some sense of how complicated our security settings are already. I'd like to contain the complexity if we can.

          Show
          Rick Hillegas added a comment - HI Bernt. Thanks for the feedback on the name of the override flag. I agree that "secure-by-default" means, at best, "has no security holes that we understand". One thing that I like about "unsecure" as a flag name is this: it allows the flag to control other security mechanisms besides the installation of a Java security manager. I'm not a big fan of introducing a lot of flags to control individual security features. I think that the discussion on DERBY-2264 gives some sense of how complicated our security settings are already. I'd like to contain the complexity if we can.
          Hide
          Bernt M. Johnsen added a comment -

          I find the -unsecure option somewhat misleading in sense that one
          could be lead to believe that without this options set, Derby would be
          secure.

          Wether or not Derby is secure (or more precicely, secure enough for a
          certain application) is a rather complex question to answer. Derby
          will only be secure enough when the user has evaluated the threat to
          his/her application and considered all security features available
          (SSL with or without peer authentication, encryption on the disk,
          running under security manager with the correct settings in the policy
          file, what kind of user authentication to use, use of privileges, SQL
          users etc) and decided what fits his/hers application.

          The option should be given a name which tells exactly what it does:
          Runs Derby without security manager. E.g. -noSecutityManager or
          something similar.

          Show
          Bernt M. Johnsen added a comment - I find the -unsecure option somewhat misleading in sense that one could be lead to believe that without this options set, Derby would be secure. Wether or not Derby is secure (or more precicely, secure enough for a certain application) is a rather complex question to answer. Derby will only be secure enough when the user has evaluated the threat to his/her application and considered all security features available (SSL with or without peer authentication, encryption on the disk, running under security manager with the correct settings in the policy file, what kind of user authentication to use, use of privileges, SQL users etc) and decided what fits his/hers application. The option should be given a name which tells exactly what it does: Runs Derby without security manager. E.g. -noSecutityManager or something similar.
          Hide
          Rick Hillegas added a comment -

          Attaching derby-2196-03-tests-01.diff. This is a unit test to verify that the network server installs a security manager with the Basic policy as expected. Makes the following changes:

          M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/_Suite.java

          Wires the test into the derbynet suite.

          A java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SecureServerTest.java

          The test itself. Tests that the server, when booted, installs a security manager or not, depending on other command-line settings.

          M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java

          Added some machinery for bringing the server up in a separate process. This test needs a separate process to avoid having to poke special test instrumentation into the network server itself.

          M java/testing/org/apache/derbyTesting/junit/SecurityManagerSetup.java
          M java/testing/org/apache/derbyTesting/junit/ServerSetup.java
          M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java

          Made some machinery public.

          Show
          Rick Hillegas added a comment - Attaching derby-2196-03-tests-01.diff. This is a unit test to verify that the network server installs a security manager with the Basic policy as expected. Makes the following changes: M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/_Suite.java Wires the test into the derbynet suite. A java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SecureServerTest.java The test itself. Tests that the server, when booted, installs a security manager or not, depending on other command-line settings. M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java Added some machinery for bringing the server up in a separate process. This test needs a separate process to avoid having to poke special test instrumentation into the network server itself. M java/testing/org/apache/derbyTesting/junit/SecurityManagerSetup.java M java/testing/org/apache/derbyTesting/junit/ServerSetup.java M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java Made some machinery public.
          Hide
          Rick Hillegas added a comment -

          Committed derby-2196-02-install-01.diff at subversion revision 506751.

          Show
          Rick Hillegas added a comment - Committed derby-2196-02-install-01.diff at subversion revision 506751.
          Hide
          Rick Hillegas added a comment -

          Attaching next piece of this work: derby-2196-02-install-01.diff. This patch does the following:

          1) Changes the network server so that it installs a security manager when the server is booted as the VM's entry point. User authentication must be turned on.

          2) Introduces a new startup option, "-unsecure" so that customers can opt out of this secure-by-default scheme if they need to.

          3) Adjusts unit tests to account for the new "unsecure" option and the requirement that user authentication be turned on when you boot the server.

          Touches the following files:

          M java/engine/org/apache/derby/iapi/reference/Property.java
          M java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java
          M java/drda/org/apache/derby/drda/NetworkServerControl.java
          M java/drda/org/apache/derby/drda/server.policy
          M java/drda/org/apache/derby/loc/drda/messages_en.properties
          M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/testProperties.java
          M java/testing/org/apache/derbyTesting/functionTests/master/testProperties.out
          M java/testing/org/apache/derbyTesting/functionTests/master/derbyrunjartest.out
          M java/testing/org/apache/derbyTesting/functionTests/master/timeslice.out
          M java/testing/org/apache/derbyTesting/functionTests/master/maxthreads.out

          Show
          Rick Hillegas added a comment - Attaching next piece of this work: derby-2196-02-install-01.diff. This patch does the following: 1) Changes the network server so that it installs a security manager when the server is booted as the VM's entry point. User authentication must be turned on. 2) Introduces a new startup option, "-unsecure" so that customers can opt out of this secure-by-default scheme if they need to. 3) Adjusts unit tests to account for the new "unsecure" option and the requirement that user authentication be turned on when you boot the server. Touches the following files: M java/engine/org/apache/derby/iapi/reference/Property.java M java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java M java/drda/org/apache/derby/drda/NetworkServerControl.java M java/drda/org/apache/derby/drda/server.policy M java/drda/org/apache/derby/loc/drda/messages_en.properties M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/testProperties.java M java/testing/org/apache/derbyTesting/functionTests/master/testProperties.out M java/testing/org/apache/derbyTesting/functionTests/master/derbyrunjartest.out M java/testing/org/apache/derbyTesting/functionTests/master/timeslice.out M java/testing/org/apache/derbyTesting/functionTests/master/maxthreads.out
          Hide
          Daniel John Debrunner added a comment -

          The issue is that there would be a security hole with huge consequences.
          A cracker might see the Derby code and think if I can set derby.derby.jar to an empty string for a remote server then I will silently have a pretty full set of abilities to maniplate that machine. And the person running the server would probably never notice. That's a pretty attractive target for a cracker to go after. Then the cracker would figure out how to do it, and maybe it's as simple as modifying the application's startup script for the server, it doesn't have to mean they can set Java system properties in a running JVM. And we know through viruses etc. that such attacks do occur. I'm sure the core vunerability at any successful attack looks vanishingly small by itself.

          Security analysis is much easier is something is impossible, rather than possible, e.g. in this case codebase can not be set to an empty string if using $

          {derby.install.url}

          /derby.jar.

          Thanks for switching to a single property. Since this is an internal property I'm wondering if a different namespace to derby.* would be more secure, e.g. $

          {org.apache.derby.install.url}

          . This might ease security analysis as we could expect that application code might have permission to set derby.* (again removing possibilities) but since this will only be used for a fixed policy file it might not help. Probably sticking with derby.install.url is good for now and a separate issue could be raised for switching the internal name if required.

          Show
          Daniel John Debrunner added a comment - The issue is that there would be a security hole with huge consequences. A cracker might see the Derby code and think if I can set derby.derby.jar to an empty string for a remote server then I will silently have a pretty full set of abilities to maniplate that machine. And the person running the server would probably never notice. That's a pretty attractive target for a cracker to go after. Then the cracker would figure out how to do it, and maybe it's as simple as modifying the application's startup script for the server, it doesn't have to mean they can set Java system properties in a running JVM. And we know through viruses etc. that such attacks do occur. I'm sure the core vunerability at any successful attack looks vanishingly small by itself. Security analysis is much easier is something is impossible, rather than possible, e.g. in this case codebase can not be set to an empty string if using $ {derby.install.url} /derby.jar. Thanks for switching to a single property. Since this is an internal property I'm wondering if a different namespace to derby.* would be more secure, e.g. $ {org.apache.derby.install.url} . This might ease security analysis as we could expect that application code might have permission to set derby.* (again removing possibilities) but since this will only be used for a fixed policy file it might not help. Probably sticking with derby.install.url is good for now and a separate issue could be raised for switching the internal name if required.
          Hide
          Rick Hillegas added a comment -

          Ha! I didn't think this issue would generate such a lively discussion. I do think the security hole is vanishingly small. But it might be the same size as the corner case I'm trying to support: the customer who puts derby.jar and derbynet.jar in separate directories. I don't feel passionately about this issue and I'm happy to go with the following:

          $

          {derby.install.url}/derby.jar
          ${derby.install.url}

          /derbynet.jar

          Show
          Rick Hillegas added a comment - Ha! I didn't think this issue would generate such a lively discussion. I do think the security hole is vanishingly small. But it might be the same size as the corner case I'm trying to support: the customer who puts derby.jar and derbynet.jar in separate directories. I don't feel passionately about this issue and I'm happy to go with the following: $ {derby.install.url}/derby.jar ${derby.install.url} /derbynet.jar
          Hide
          Daniel John Debrunner added a comment -

          +1 on forcilbly setting the single property as described.
          probably also need to ensure that the policy file is coming from the derbynet.jar that is actually running.

          but it doesn't close the hole.

          the hole really exists when someone uses a modified version of the template policy file and continues to use these properties for the codebase.
          Derby should not be recommending a policy file that has the potential to such an attack.

          Show
          Daniel John Debrunner added a comment - +1 on forcilbly setting the single property as described. probably also need to ensure that the policy file is coming from the derbynet.jar that is actually running. but it doesn't close the hole. the hole really exists when someone uses a modified version of the template policy file and continues to use these properties for the codebase. Derby should not be recommending a policy file that has the potential to such an attack.
          Hide
          Daniel John Debrunner added a comment -

          > I think that that hole exists regardless of whether the black-hat jar file is $

          {derby.install.url} or ${derby.install.url}

          /lib/derby.jar.

          I think that a codebase in a policy file of $

          {derby.install.url} is a much bigger hole than ${derby.install.url}

          /lib/derby.jar
          and has the potential to be beneifical to hostile clients.
          The reasons is that if I can modify $

          {derby.install.url}

          than I can point to any code including the special token of all code.

          If I have the ability to set a system property on a remote host but don't have the ability to install software there, then I can could potentially use a remote server to grant a wide range of permissions to all code including SQL Java routines, thus allowing remote SQL Java routine defined by me remotely to have a wide range of permissions.

          Limiting the hole to jar files called derby.jar in a lib folder is a much smaller exposure and cannot be exploited by SQL Java routines.

          Maybe a remote client having the ability to set a system property is somewhat unlikely, but to be clear it need not be the permission to set all system properties, just one specific one, or the ability to set one in the derby.* namespace. Thus someone else may set up a policy file that allows some code to set derby.* properties as system properties and not realize they could have opened up everything.

          We don't have to expose these properties in the template policy, it could have its codebase manipulated in the build process to be something like (actual text): replace_with_path_to_derby_install/lib/derby.jar
          Ie. something that forces the application developer to edit it.
          It is a template for a policy file, that we expect the user to modify anyway.

          Show
          Daniel John Debrunner added a comment - > I think that that hole exists regardless of whether the black-hat jar file is $ {derby.install.url} or ${derby.install.url} /lib/derby.jar. I think that a codebase in a policy file of $ {derby.install.url} is a much bigger hole than ${derby.install.url} /lib/derby.jar and has the potential to be beneifical to hostile clients. The reasons is that if I can modify $ {derby.install.url} than I can point to any code including the special token of all code. If I have the ability to set a system property on a remote host but don't have the ability to install software there, then I can could potentially use a remote server to grant a wide range of permissions to all code including SQL Java routines, thus allowing remote SQL Java routine defined by me remotely to have a wide range of permissions. Limiting the hole to jar files called derby.jar in a lib folder is a much smaller exposure and cannot be exploited by SQL Java routines. Maybe a remote client having the ability to set a system property is somewhat unlikely, but to be clear it need not be the permission to set all system properties, just one specific one, or the ability to set one in the derby.* namespace. Thus someone else may set up a policy file that allows some code to set derby.* properties as system properties and not realize they could have opened up everything. We don't have to expose these properties in the template policy, it could have its codebase manipulated in the build process to be something like (actual text): replace_with_path_to_derby_install/lib/derby.jar Ie. something that forces the application developer to edit it. It is a template for a policy file, that we expect the user to modify anyway.
          Hide
          Rick Hillegas added a comment -

          In coding this next piece, it seems best to me that the Network Server should forcibly set derby.derby.jar and derby.derbynet.jar whenever it forcibly installs a security manager. I think that this closes the security hole and eliminates any need to expose these properties in the user guides.

          Show
          Rick Hillegas added a comment - In coding this next piece, it seems best to me that the Network Server should forcibly set derby.derby.jar and derby.derbynet.jar whenever it forcibly installs a security manager. I think that this closes the security hole and eliminates any need to expose these properties in the user guides.
          Hide
          Rick Hillegas added a comment -

          Thanks for the additional feedback, Dan. If you think it's ok to not document these properties in the user guides, then I'm fine with removing that task from the functional spec. I don't see much point in exposing these to users and I agree that they are just pieces of our internal plumbing--although we at least half-expose them to customers by including them in the template policy file we ship with the release.

          You point out an interesting security hole. I think that that hole exists regardless of whether the black-hat jar file is $

          {derby.install.url} or ${derby.install.url}

          /lib/derby.jar. I don't know how serious that hole is. I suspect that the person who has access to setting system properties also has the power to do a lot of other harm.

          To close that specific security hole, we could go back to the original idea of having the network server cook up the Basic policy on the fly. That is, we would not paramterize the location of the codesources.

          Show
          Rick Hillegas added a comment - Thanks for the additional feedback, Dan. If you think it's ok to not document these properties in the user guides, then I'm fine with removing that task from the functional spec. I don't see much point in exposing these to users and I agree that they are just pieces of our internal plumbing--although we at least half-expose them to customers by including them in the template policy file we ship with the release. You point out an interesting security hole. I think that that hole exists regardless of whether the black-hat jar file is $ {derby.install.url} or ${derby.install.url} /lib/derby.jar. I don't know how serious that hole is. I suspect that the person who has access to setting system properties also has the power to do a lot of other harm. To close that specific security hole, we could go back to the original idea of having the network server cook up the Basic policy on the fly. That is, we would not paramterize the location of the codesources.
          Hide
          Daniel John Debrunner added a comment -

          Can you update the functional spec with how these two properties $

          {derby.derby.jar}

          and derby.derbynet.jar will be used by end users and what benefit having two properties provides? They seem to be really strange to me as they will only ever be used by a policy file that has been modified by the user. The network server might be using them internally when it boots using its own default policy but that is really an implementation detail that is not relevant for user documentation. Also I'm assuming that it is expected that derby.jar and derbynet.jar come from the same directory location since derbynet.jar is dependent on derby.jar.

          I am concerned that use of two properties leads to a policy file that has a potential security risk in it. Namely that by setting these properties to point to other code, that code will get a wide range of permissions including access to all files. The worst case is setting derby.derby.jar= (empty string). That would seem to grant these permissions to all code.

          Having the codebase in the policy file instead be something like
          $

          {derby.install.url}

          /lib/derby.jar
          limits the exposure if there is a security hole where a remote user can set derby.install.home.

          Of course maybe there is some benefit to the two properties as you have described them, and I'm just not seeing it.

          Show
          Daniel John Debrunner added a comment - Can you update the functional spec with how these two properties $ {derby.derby.jar} and derby.derbynet.jar will be used by end users and what benefit having two properties provides? They seem to be really strange to me as they will only ever be used by a policy file that has been modified by the user. The network server might be using them internally when it boots using its own default policy but that is really an implementation detail that is not relevant for user documentation. Also I'm assuming that it is expected that derby.jar and derbynet.jar come from the same directory location since derbynet.jar is dependent on derby.jar. I am concerned that use of two properties leads to a policy file that has a potential security risk in it. Namely that by setting these properties to point to other code, that code will get a wide range of permissions including access to all files. The worst case is setting derby.derby.jar= (empty string). That would seem to grant these permissions to all code. Having the codebase in the policy file instead be something like $ {derby.install.url} /lib/derby.jar limits the exposure if there is a security hole where a remote user can set derby.install.home. Of course maybe there is some benefit to the two properties as you have described them, and I'm just not seeing it.
          Hide
          Rick Hillegas added a comment -

          Committed derby-2196-01-print-03.diff at subversion revision 504661.

          Show
          Rick Hillegas added a comment - Committed derby-2196-01-print-03.diff at subversion revision 504661.
          Hide
          Rick Hillegas added a comment -

          Attaching a third rev of this patch: derby-2196-01-print-03.diff. This patch eliminates the "policy" command and, instead, checks in a template policy file for use by the server and for packaging in the release. This patch touches the following files:

          A java/drda/org/apache/derby/drda/server.policy – the Basic server policy

          M java/drda/org/apache/derby/drda/build.xml – copies the policy from the source to the class tree

          M build.xml – puts the Basic policy in derbynet.jar

          M tools/release/build.xml – puts the policy file in demo/templates at release-time

          Show
          Rick Hillegas added a comment - Attaching a third rev of this patch: derby-2196-01-print-03.diff. This patch eliminates the "policy" command and, instead, checks in a template policy file for use by the server and for packaging in the release. This patch touches the following files: A java/drda/org/apache/derby/drda/server.policy – the Basic server policy M java/drda/org/apache/derby/drda/build.xml – copies the policy from the source to the class tree M build.xml – puts the Basic policy in derbynet.jar M tools/release/build.xml – puts the policy file in demo/templates at release-time
          Hide
          Rick Hillegas added a comment -

          Thanks for the quick feedback, Dan. I don't think having two properties is going to be that confusing, although I agree that it is overkill for most users. I'm content to go with two properties right now. If we feel the need to sand this down later, we can revisit this decision.

          Show
          Rick Hillegas added a comment - Thanks for the quick feedback, Dan. I don't think having two properties is going to be that confusing, although I agree that it is overkill for most users. I'm content to go with two properties right now. If we feel the need to sand this down later, we can revisit this decision.
          Hide
          Daniel John Debrunner added a comment -

          I think the two properties in rev 6

          {derby.derby.jar and derby.derbynet.jar}

          are overkill.
          I think a single property that is the location of the derby jar files is sufficient and will be clearer to readers of the template policy.

          If someone is repackaging Derby and is copying and modifying the template file then they are unlikely to use $

          {derby.derby.jar}

          to refer to their own application jar file that includes Derby.

          I'm also believe that anyone that does package the Derby classes in their own jars is not really a concern for the Derby project. Derby's security is in part based upon its jar file layout, due to such concepts as jar signing. It seems hard for the project to provide any guarantees when the code is packaged by someone else.

          I think the typical repackaging now is to include multiple jars and have the application's jar file have a classpath manifest that refers to other jar files, such as derby.jar.

          Show
          Daniel John Debrunner added a comment - I think the two properties in rev 6 {derby.derby.jar and derby.derbynet.jar} are overkill. I think a single property that is the location of the derby jar files is sufficient and will be clearer to readers of the template policy. If someone is repackaging Derby and is copying and modifying the template file then they are unlikely to use $ {derby.derby.jar} to refer to their own application jar file that includes Derby. I'm also believe that anyone that does package the Derby classes in their own jars is not really a concern for the Derby project. Derby's security is in part based upon its jar file layout, due to such concepts as jar signing. It seems hard for the project to provide any guarantees when the code is packaged by someone else. I think the typical repackaging now is to include multiple jars and have the application's jar file have a classpath manifest that refers to other jar files, such as derby.jar.
          Hide
          Rick Hillegas added a comment -

          Attaching rev 6 of the functional spec. This removes the "policy" command. Instead, we propose to ship and use a default policy file, which customers can refine. Thanks to Dan and Andrew for helping to puzzle through this.

          Show
          Rick Hillegas added a comment - Attaching rev 6 of the functional spec. This removes the "policy" command. Instead, we propose to ship and use a default policy file, which customers can refine. Thanks to Dan and Andrew for helping to puzzle through this.
          Hide
          Daniel John Debrunner added a comment -

          Not sure what "trick" you need to "force" it.

          Fetching the resource will automatically get it as a valid URL. That's what the code I pointed you to does.
          It's doing exactly what you require, setting the security manager to point to a policy file in a jar file (when the tests are run as jars).

          Show
          Daniel John Debrunner added a comment - Not sure what "trick" you need to "force" it. Fetching the resource will automatically get it as a valid URL. That's what the code I pointed you to does. It's doing exactly what you require, setting the security manager to point to a policy file in a jar file (when the tests are run as jars).
          Hide
          Rick Hillegas added a comment -

          Thanks, Dan. I think I know enough to do some damage now. I think the trick is to force java.security.policy to be an URL which begins with the "jar:" protocol. See http://www.exampledepot.com/egs/java.net/JarUrl.html?l=rel

          I'll run some experiments and probably post a new functional spec.

          In other news, what do you think of Andrew's suggestion that we put this template file under demo? Maybe demo/templates? If no-one objects to this, that's what I'll put in the next rev of the functional spec.

          Show
          Rick Hillegas added a comment - Thanks, Dan. I think I know enough to do some damage now. I think the trick is to force java.security.policy to be an URL which begins with the "jar:" protocol. See http://www.exampledepot.com/egs/java.net/JarUrl.html?l=rel I'll run some experiments and probably post a new functional spec. In other news, what do you think of Andrew's suggestion that we put this template file under demo? Maybe demo/templates? If no-one objects to this, that's what I'll put in the next rev of the functional spec.
          Hide
          Daniel John Debrunner added a comment -

          org.apache.derbyTesting.junit.SecurityManagerSetup.installSecurityManager

          org.apache.derbyTesting.junit.SecurityManagerSetup.setSecurityPolicy

          Show
          Daniel John Debrunner added a comment - org.apache.derbyTesting.junit.SecurityManagerSetup.installSecurityManager org.apache.derbyTesting.junit.SecurityManagerSetup.setSecurityPolicy
          Hide
          Rick Hillegas added a comment -

          Thanks, Dan. I need to buy a clue: How is the policy file loaded as a resource? Can you point me at some sample code which does this?

          Show
          Rick Hillegas added a comment - Thanks, Dan. I need to buy a clue: How is the policy file loaded as a resource? Can you point me at some sample code which does this?
          Hide
          Andrew McIntyre added a comment -

          Do we need a 'templates' directory? Will there be anything but this one policy file in it? Why not keep it in demo?

          Show
          Andrew McIntyre added a comment - Do we need a 'templates' directory? Will there be anything but this one policy file in it? Why not keep it in demo?
          Hide
          Daniel John Debrunner added a comment -

          1) Yes
          2) Yes
          3) No - the policy file is accessed directly from the jar file as a resource

          Show
          Daniel John Debrunner added a comment - 1) Yes 2) Yes 3) No - the policy file is accessed directly from the jar file as a resource
          Hide
          Rick Hillegas added a comment -

          Let me make sure I understand what you are proposing:

          1) We ship the default policy file in a human-accessilbe location, say a "templates" directory parallel to bin, doc, and lib

          2) We also bundle the default policy file inside derbynet.jar.

          3) When the server comes up, it copies the default policy file out of derbynet.jar into $

          {user.dir}

          so that it is visible to the security machinery.

          Show
          Rick Hillegas added a comment - Let me make sure I understand what you are proposing: 1) We ship the default policy file in a human-accessilbe location, say a "templates" directory parallel to bin, doc, and lib 2) We also bundle the default policy file inside derbynet.jar. 3) When the server comes up, it copies the default policy file out of derbynet.jar into $ {user.dir} so that it is visible to the security machinery.
          Hide
          Daniel John Debrunner added a comment -

          The codebases can also be properties, look at the policy file for the test harness.

          Yes I mean a security subdirectory in the release directory, but it could be done other ways, a example in the documentation that could be cut & pasted might be enough. The expectation is the file is going to be modified anyway.

          If we do have a security directory I wasn't thinking that the network server would use the file from that location, it might be easier to keep the policy file contained in the network jar file. We don't need to "maintain" such a file in two locations as they can be sourced from the same location during the build. With that a better name for the subdirectory might be "example" or "templates" or something along those lines.

          Show
          Daniel John Debrunner added a comment - The codebases can also be properties, look at the policy file for the test harness. Yes I mean a security subdirectory in the release directory, but it could be done other ways, a example in the documentation that could be cut & pasted might be enough. The expectation is the file is going to be modified anyway. If we do have a security directory I wasn't thinking that the network server would use the file from that location, it might be easier to keep the policy file contained in the network jar file. We don't need to "maintain" such a file in two locations as they can be sourced from the same location during the build. With that a better name for the subdirectory might be "example" or "templates" or something along those lines.
          Hide
          Rick Hillegas added a comment -

          Correction: There are still two important parameters in the policy file, viz., the codebases which receive the permissions. The network server still needs to figure out where those codebases are. I think we don't want to maintain the default policy in two places, that is, inside the network server and separately in the release tree.

          Show
          Rick Hillegas added a comment - Correction: There are still two important parameters in the policy file, viz., the codebases which receive the permissions. The network server still needs to figure out where those codebases are. I think we don't want to maintain the default policy in two places, that is, inside the network server and separately in the release tree.
          Hide
          Rick Hillegas added a comment -

          Dan> Do we really need a 'policy' command? Why not just have the basic policy file in the release folder under a new folder such as security or policies? Much easier for anyone to find rather than having to learn a command.

          When we started out, it looked as though the policy file might have to be parameterized according to command line arguments. I'm cautiously hopeful right now that that is no longer true. That means the only variables in the policy file now are the language-sensitive comments which explain how to customize the file. I suppose that's just a piece of sugar and we could rely on the user guides to handle this.

          I'm not clear on what you mean by "release directory". Do you think that we should create a new subdirectory called "security" which is parallel to bin, doc, and lib?

          Show
          Rick Hillegas added a comment - Dan> Do we really need a 'policy' command? Why not just have the basic policy file in the release folder under a new folder such as security or policies? Much easier for anyone to find rather than having to learn a command. When we started out, it looked as though the policy file might have to be parameterized according to command line arguments. I'm cautiously hopeful right now that that is no longer true. That means the only variables in the policy file now are the language-sensitive comments which explain how to customize the file. I suppose that's just a piece of sugar and we could rely on the user guides to handle this. I'm not clear on what you mean by "release directory". Do you think that we should create a new subdirectory called "security" which is parallel to bin, doc, and lib?
          Hide
          Daniel John Debrunner added a comment -

          Do we really need a 'policy' command? Why not just have the basic policy file in the release folder under a new folder such as security or policies? Much easier for anyone to find rather than having to learn a command.

          Show
          Daniel John Debrunner added a comment - Do we really need a 'policy' command? Why not just have the basic policy file in the release folder under a new folder such as security or policies? Much easier for anyone to find rather than having to learn a command.
          Hide
          Rick Hillegas added a comment -

          Thanks for the quick review, John!

          The need to set derby.system.home and derby.drda.host is expected. I should have pointed that out. A follow-on patch will set those variables if they aren't already set.

          Thanks for catching the problems with running the policy-printer from derbyrun.jar and derbynet.jar standalone. have come up with what looks like a simpler way to find the target codebases. The improved scheme should work for more cases.

          I am attaching rev 2 of this patch: derby-2196-01-print-02.diff.

          Show
          Rick Hillegas added a comment - Thanks for the quick review, John! The need to set derby.system.home and derby.drda.host is expected. I should have pointed that out. A follow-on patch will set those variables if they aren't already set. Thanks for catching the problems with running the policy-printer from derbyrun.jar and derbynet.jar standalone. have come up with what looks like a simpler way to find the target codebases. The improved scheme should work for more cases. I am attaching rev 2 of this patch: derby-2196-01-print-02.diff.
          Hide
          John H. Embretsen added a comment -

          Some comments to 'derby-2196-01-print-01.diff':

          I found the following issues trying out the patch and the generated policy:

          • Connections are not allowed unless both derby.drda.host and derby.system.home have been set explicitly:
          • without -Dderby.drda.host=<host>:

          java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:44561 accept,resolve)

          • without -Dderby.system.home=<userDir>:

          java.security.AccessControlExceptionaccess denied (java.util.PropertyPermission user.dir read)XJ001.U
          (error received by client)

          • the "policy" command does not work when running it using jar files ("java -jar derbyrun.jar server policy" or "java -jar derbynet.jar policy")

          Regarding allowing a range of port number instead of all ports, I think we can safely assume that the ServerSocket/Socket implementations will never dynamically assign incoming connections to the "well known" or "reserved" ports (port numbers 1024 and lower). I have not been able to confirm this for sure, though.

          Show
          John H. Embretsen added a comment - Some comments to 'derby-2196-01-print-01.diff': I found the following issues trying out the patch and the generated policy: Connections are not allowed unless both derby.drda.host and derby.system.home have been set explicitly: without -Dderby.drda.host=<host>: java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:44561 accept,resolve) without -Dderby.system.home=<userDir>: java.security.AccessControlExceptionaccess denied (java.util.PropertyPermission user.dir read)XJ001.U (error received by client) the "policy" command does not work when running it using jar files ("java -jar derbyrun.jar server policy" or "java -jar derbynet.jar policy") Regarding allowing a range of port number instead of all ports, I think we can safely assume that the ServerSocket/Socket implementations will never dynamically assign incoming connections to the "well known" or "reserved" ports (port numbers 1024 and lower). I have not been able to confirm this for sure, though.
          Hide
          Rick Hillegas added a comment -

          Dan> Should the permission then be broken into two, one for the accept on the distinguished port, and then connect on all ports or a range of port numbers?

          I tried breaking this into a permission to accept on the distinguished port and then another permission to connect on all ports. Then I attempted to connect to the server. This raised a security exception claiming that I needed accept permission on the second connection. So I think that we could break this into an accept on the distinguished port and then an accept on a range of port numbers. However, right now I don't see any way to figure out what that range would be. It looks like Derby is just relying on ServerSocket to make up a port number. I think we would have to write some more code to restrict the range of ports--probably this should be parameterized so that the customer can tell us what range of ports to use. I think this would be a useful evolution of the work begun in this JIRA but, in the interests of incremental development, I'd like to defer that work.

          Show
          Rick Hillegas added a comment - Dan> Should the permission then be broken into two, one for the accept on the distinguished port, and then connect on all ports or a range of port numbers? I tried breaking this into a permission to accept on the distinguished port and then another permission to connect on all ports. Then I attempted to connect to the server. This raised a security exception claiming that I needed accept permission on the second connection. So I think that we could break this into an accept on the distinguished port and then an accept on a range of port numbers. However, right now I don't see any way to figure out what that range would be. It looks like Derby is just relying on ServerSocket to make up a port number. I think we would have to write some more code to restrict the range of ports--probably this should be parameterized so that the customer can tell us what range of ports to use. I think this would be a useful evolution of the work begun in this JIRA but, in the interests of incremental development, I'd like to defer that work.
          Hide
          Daniel John Debrunner added a comment -

          Rick> 2) I had to broaden the socket accept privileges to all port numbers. This is because, after accepting a connection request on the distinguished port, the server then opens up a connection with the client on another port, whose number is unpredictable.

          Should the permission then be broken into two, one for the accept on the distinguished port, and then connect on all ports or a range of port numbers?

          Show
          Daniel John Debrunner added a comment - Rick> 2) I had to broaden the socket accept privileges to all port numbers. This is because, after accepting a connection request on the distinguished port, the server then opens up a connection with the client on another port, whose number is unpredictable. Should the permission then be broken into two, one for the accept on the distinguished port, and then connect on all ports or a range of port numbers?
          Hide
          Rick Hillegas added a comment -

          Attaching a patch for the first piece of this work. This patch implements the Network Server's "policy" command, which prints out the Basic policy. Using this policy, I have successfully brought the server up and down, created a database, and imported a jar file. This patch touches the following files:

          M java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java
          M java/drda/org/apache/derby/loc/drda/messages_en.properties

          Here is the Basic policy printed by the "policy" command:

          grant codeBase "file:/export/home/rh161140/derby/mainline/trunk/jars/insane/derby.jar"
          {
          //
          // These permissions are needed for everyday, embedded Derby usage.
          //
          permission java.lang.RuntimePermission "createClassLoader";
          permission java.util.PropertyPermission "derby.*", "read";
          permission java.io.FilePermission "$

          {derby.system.home}","read";
          permission java.io.FilePermission "${derby.system.home}

          $

          {/}

          -", "read,write,delete";

          //
          // This permission lets you backup and restore databases
          // to and from arbitrary locations in your file system.
          //
          // This permission also lets you import/export data to and from
          // arbitrary locations in your file system.
          //
          // You may want to restrict this access to specific directories.
          //
          permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete";
          };

          grant codeBase "file:/export/home/rh161140/derby/mainline/trunk/jars/insane/derbynet.jar"
          {
          //
          // This permission lets the Network Server manage connections from clients.
          //
          permission java.net.SocketPermission "$

          {derby.drda.host}

          :*", "accept";
          };

          Show
          Rick Hillegas added a comment - Attaching a patch for the first piece of this work. This patch implements the Network Server's "policy" command, which prints out the Basic policy. Using this policy, I have successfully brought the server up and down, created a database, and imported a jar file. This patch touches the following files: M java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java M java/drda/org/apache/derby/loc/drda/messages_en.properties Here is the Basic policy printed by the "policy" command: grant codeBase "file:/export/home/rh161140/derby/mainline/trunk/jars/insane/derby.jar" { // // These permissions are needed for everyday, embedded Derby usage. // permission java.lang.RuntimePermission "createClassLoader"; permission java.util.PropertyPermission "derby.*", "read"; permission java.io.FilePermission "$ {derby.system.home}","read"; permission java.io.FilePermission "${derby.system.home} $ {/} -", "read,write,delete"; // // This permission lets you backup and restore databases // to and from arbitrary locations in your file system. // // This permission also lets you import/export data to and from // arbitrary locations in your file system. // // You may want to restrict this access to specific directories. // permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete"; }; grant codeBase "file:/export/home/rh161140/derby/mainline/trunk/jars/insane/derbynet.jar" { // // This permission lets the Network Server manage connections from clients. // permission java.net.SocketPermission "$ {derby.drda.host} :*", "accept"; };
          Hide
          Rick Hillegas added a comment -

          Attaching rev 5 of this spec. This makes the following changes based on my experience in implementing the first piece of this work:

          1) There is already a -b option. So I can't use that for printing out the Basic policy. Instead, I have gone back to David's suggestion that we model policy-printing as a separate command rather than a dash-option. This makes more sense to me now that we only have a startup policy.

          2) I had to broaden the socket accept privileges to all port numbers. This is because, after accepting a connection request on the distinguished port, the server then opens up a connection with the client on another port, whose number is unpredictable.

          Show
          Rick Hillegas added a comment - Attaching rev 5 of this spec. This makes the following changes based on my experience in implementing the first piece of this work: 1) There is already a -b option. So I can't use that for printing out the Basic policy. Instead, I have gone back to David's suggestion that we model policy-printing as a separate command rather than a dash-option. This makes more sense to me now that we only have a startup policy. 2) I had to broaden the socket accept privileges to all port numbers. This is because, after accepting a connection request on the distinguished port, the server then opens up a connection with the client on another port, whose number is unpredictable.
          Hide
          Rick Hillegas added a comment -

          Attaching rev 4 of the functional spec. This incorporates Dan's suggestion (in a comment attached to DERBY-2206): to avoid giving a false sense of security, you must enable authentication when booting the server.

          Show
          Rick Hillegas added a comment - Attaching rev 4 of the functional spec. This incorporates Dan's suggestion (in a comment attached to DERBY-2206 ): to avoid giving a false sense of security, you must enable authentication when booting the server.
          Hide
          Rick Hillegas added a comment -

          Attach version 3 of the functional spec, incorporating Dan's feedback.

          Show
          Rick Hillegas added a comment - Attach version 3 of the functional spec, incorporating Dan's feedback.
          Hide
          Rick Hillegas added a comment -

          Thanks for the quick feedback, Dan. I have incorporated your comments into my private version of the spec. I will wait a little while for more comments to trickle in before posting the new rev.

          Show
          Rick Hillegas added a comment - Thanks for the quick feedback, Dan. I have incorporated your comments into my private version of the spec. I will wait a little while for more comments to trickle in before posting the new rev.
          Hide
          Daniel John Debrunner added a comment -

          For the all files, I do not think $

          {/}/- is portable. Why not use the defined special token <<ALL FILES>>?
          Other possibilities are ${user.home}${/}

          -and $

          {user.dir}

          $

          {/}

          -

          I think the socket permission for derbynet.jar can simply be fixed as:

          permission java.net.SocketPermission("$

          {derby.drda.host}

          :$

          {derby.drda.portNumber}

          ", "accept");

          and like derby.system.home, set those properties as required if they are not set. Note those values can be set from derby.properties.

          In the first row of the upgrade table I think you also need to point out that the application is now restricted by the security manager for its server-side code. This is probably more important than "bugs which plague Derby".

          Show
          Daniel John Debrunner added a comment - For the all files, I do not think $ {/}/- is portable. Why not use the defined special token <<ALL FILES>>? Other possibilities are ${user.home}${/} -and $ {user.dir} $ {/} - I think the socket permission for derbynet.jar can simply be fixed as: permission java.net.SocketPermission("$ {derby.drda.host} :$ {derby.drda.portNumber} ", "accept"); and like derby.system.home, set those properties as required if they are not set. Note those values can be set from derby.properties. In the first row of the upgrade table I think you also need to point out that the application is now restricted by the security manager for its server-side code. This is probably more important than "bugs which plague Derby".
          Hide
          Rick Hillegas added a comment -

          Attach second rev of a functional spec for this feature. This rev incorporates feedback on the previous rev from Dan and John.

          Show
          Rick Hillegas added a comment - Attach second rev of a functional spec for this feature. This rev incorporates feedback on the previous rev from Dan and John.
          Hide
          Rick Hillegas added a comment -

          Thanks for the feedback, John. In the next rev of the spec, I will clarify all of the points you raise.

          Show
          Rick Hillegas added a comment - Thanks for the feedback, John. In the next rev of the spec, I will clarify all of the points you raise.
          Hide
          John H. Embretsen added a comment -

          Good work, here are my comments:

          a) If I understand this correctly, there is actually no point in using the security manager when using the shutdown command, right? If so, I agree that the admin guide example is confusing.

          b) Which SocketPermissions will be default (for the start command)? Granting "accept, connect, resolve" for "localhost" and "127.0.0.1", or something else?

          c) I think the spec could be clearer on which parts of the basic policy will depend on parameters/options. Or, which parameters options will/might impact the basic policy.

          d) Regarding the upgrade scenarios, I think it would be better (less misleading) to call the "Insecure Standalone Server" scenario "Default Standalone Server" or something to that regard instead, since the server is only (totally) insecure with old versions, not new ones.

          e) I think it is good to have a relatively easy way to disable automatic security manager installation. Whether the option is called -i, -disableSecurityManager or something else does not matter much to me.

          f) At first I was thinking that "None" is a more intuitive name for the "Open" policy (because no "real" policy is used), but I guess it doesn't matter. Just thinking loud

          Show
          John H. Embretsen added a comment - Good work, here are my comments: a) If I understand this correctly, there is actually no point in using the security manager when using the shutdown command, right? If so, I agree that the admin guide example is confusing. b) Which SocketPermissions will be default (for the start command)? Granting "accept, connect, resolve" for "localhost" and "127.0.0.1", or something else? c) I think the spec could be clearer on which parts of the basic policy will depend on parameters/options. Or, which parameters options will/might impact the basic policy. d) Regarding the upgrade scenarios, I think it would be better (less misleading) to call the "Insecure Standalone Server" scenario "Default Standalone Server" or something to that regard instead, since the server is only (totally) insecure with old versions, not new ones. e) I think it is good to have a relatively easy way to disable automatic security manager installation. Whether the option is called -i, -disableSecurityManager or something else does not matter much to me. f) At first I was thinking that "None" is a more intuitive name for the "Open" policy (because no "real" policy is used), but I guess it doesn't matter. Just thinking loud
          Hide
          Rick Hillegas added a comment -

          Thanks for the quick response, Dan.

          1) I agree that it would be better to grant the file/property/classloader permissions just to derby.jar and the socket permission just to derbynet.jar. The example policy file given in the current Admin Guide should probably be revised the same way.

          2) I will reword the sentence on classloaders.

          3) I like the idea of setting derby.system.home if it isn't set and then just having one set of permissions for derby.jar. I think that the second example policy file in the Developer's Guide is just wrong when it grants permissions to the file system rooted under derby.system.home when that property is not set.

          4) Thanks for reminding me about the backup/import discussion. The Basic policy can just grant blanket read/write/delete to the whole file system (with a suitable comment).

          5) Thanks for quizzing me about the rationale for the shutdown policy. I think I have misunderstood the comments in the policy in the Admin Guide. I agree that we don't need a shutdown policy and those extra socket permissions are intended for the running server.

          6) I think I understand your misgivings about the easy-to-use flag which disables default security. However, I also see the value in makiing it easy for customers to get the behavior they want. Are you concerned that this could be abused accidentally?

          Show
          Rick Hillegas added a comment - Thanks for the quick response, Dan. 1) I agree that it would be better to grant the file/property/classloader permissions just to derby.jar and the socket permission just to derbynet.jar. The example policy file given in the current Admin Guide should probably be revised the same way. 2) I will reword the sentence on classloaders. 3) I like the idea of setting derby.system.home if it isn't set and then just having one set of permissions for derby.jar. I think that the second example policy file in the Developer's Guide is just wrong when it grants permissions to the file system rooted under derby.system.home when that property is not set. 4) Thanks for reminding me about the backup/import discussion. The Basic policy can just grant blanket read/write/delete to the whole file system (with a suitable comment). 5) Thanks for quizzing me about the rationale for the shutdown policy. I think I have misunderstood the comments in the policy in the Admin Guide. I agree that we don't need a shutdown policy and those extra socket permissions are intended for the running server. 6) I think I understand your misgivings about the easy-to-use flag which disables default security. However, I also see the value in makiing it easy for customers to get the behavior they want. Are you concerned that this could be abused accidentally?
          Hide
          Daniel John Debrunner added a comment -

          Looks good - some initial comments:

          In the "Basic Policy" section the spec switches between stating the permissions will be granted to "Derby" and granted to specific jar files. I think stating the specific jar files is much clearer.

          No idea what this means:
          "permission to establish insulating classloaders per connection"

          The section for not having derby.system.home set has a permission that references derby.system.home.

          As an alternative to when derby.system.home is not set, consider having the network server set derby.system.home to the current directory. This would then have a single format for the policy file rather than two paths.

          I don't think derbynet.jar needs permissions to access the database files, e.g. $

          {derby.system.home}

          /-

          derby.jar does not need to be granted any SocketPermission

          Should the socket permission in "Basic Startup Policy" have similar functionality to the one in "Basic Shutdown Policy" in that localhost is used if -h is not used etc? Should the port number be in the policy file?

          Spec does not reflect the discussion on the list about other file permissions, e.g. for backup etc.

          I don't see (or understand) any rationale for the "Basic Shutdown Policy". What security hole is this trying to close?
          Maybe the answer to this could also explain why the other policy is called ""Basic Shutdown Policy"", when it's the policy for a running server not just startup time.

          I wonder why if the "Open policy" is not recommended a really easy way to use it is provided.

          Show
          Daniel John Debrunner added a comment - Looks good - some initial comments: In the "Basic Policy" section the spec switches between stating the permissions will be granted to "Derby" and granted to specific jar files. I think stating the specific jar files is much clearer. No idea what this means: "permission to establish insulating classloaders per connection" The section for not having derby.system.home set has a permission that references derby.system.home. As an alternative to when derby.system.home is not set, consider having the network server set derby.system.home to the current directory. This would then have a single format for the policy file rather than two paths. I don't think derbynet.jar needs permissions to access the database files, e.g. $ {derby.system.home} /- derby.jar does not need to be granted any SocketPermission Should the socket permission in "Basic Startup Policy" have similar functionality to the one in "Basic Shutdown Policy" in that localhost is used if -h is not used etc? Should the port number be in the policy file? Spec does not reflect the discussion on the list about other file permissions, e.g. for backup etc. I don't see (or understand) any rationale for the "Basic Shutdown Policy". What security hole is this trying to close? Maybe the answer to this could also explain why the other policy is called ""Basic Shutdown Policy"", when it's the policy for a running server not just startup time. I wonder why if the "Open policy" is not recommended a really easy way to use it is provided.
          Hide
          Rick Hillegas added a comment -

          Attached first draft of functional spec based on wiki page. Community feedback appreciated.

          Show
          Rick Hillegas added a comment - Attached first draft of functional spec based on wiki page. Community feedback appreciated.
          Show
          Daniel John Debrunner added a comment - Wiki page at: http://wiki.apache.org/db-derby/SecurityExpectations

            People

            • Assignee:
              Rick Hillegas
              Reporter:
              Daniel John Debrunner
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development