Derby
  1. Derby
  2. DERBY-4990

Documentation should state a custom security policy being required to use LDAP in conjunction with network driver

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.8.1.2
    • Component/s: Documentation
    • Labels:
      None
    • Bug behavior facts:
      Security

      Description

      The documentation is lacking a statement that defining and using a >custom< security manager template is required when wanting to use LDAP authorization provider in conjunction with the network driver client. driver. Otherwise, i.e. just using the default security policy will lead to socket permission errors. Details on which permission exactely needs to be granted to which code base would be very helpful.

      Chapter 'Running Derby under a security manager', section 'granting permissions to Derby' in the Developer's guide seems a good place to mention the permission java.net.SocketPermission as optional, but required to be set when wanting to use LDAP authorization in conjunction with the network client driver and defining the authorisation provider properties as system-level properties.

      Adding this to the documentation and preferrably also providing some more guidance seems desirable as migrating off the builtin user system to LDAP is strongly recommened and the documentation has explicit statements about security risks otherwise incurred.

      I also realized that the template included in the documentation at http://db.apache.org/derby/docs/10.7/adminguide/tadminnetservbasic.html and the default template included in 10.7.1.1 software are no longer in sync.

      1. tadminnetservcustom.html
        7 kB
        Kim Haase
      2. tadminnetservcustom.html
        7 kB
        Kim Haase
      3. DERBY-4990b.diff
        1 kB
        Dag H. Wanvik
      4. DERBY-4990-2.zip
        10 kB
        Kim Haase
      5. DERBY-4990-2.stat
        0.2 kB
        Kim Haase
      6. DERBY-4990-2.diff
        6 kB
        Kim Haase
      7. DERBY-4990.diff
        1 kB
        Kim Haase

        Issue Links

          Activity

          Hide
          Kim Haase added a comment -

          Closing, since the fix appeared in the online docs several months ago.

          Show
          Kim Haase added a comment - Closing, since the fix appeared in the online docs several months ago.
          Hide
          Kim Haase added a comment -

          Committed patch DERBY-4990-2.diff to documentation trunk at revision 1074163.

          Show
          Kim Haase added a comment - Committed patch DERBY-4990 -2.diff to documentation trunk at revision 1074163.
          Hide
          Kim Haase added a comment -

          I plan to commit DERBY-4990-2.diff tomorrow or soon after, unless I hear otherwise.

          Show
          Kim Haase added a comment - I plan to commit DERBY-4990 -2.diff tomorrow or soon after, unless I hear otherwise.
          Hide
          Kim Haase added a comment -

          Attaching DERBY-4990-2.diff, DERBY-4990-2.stat, and DERBY-4990-2.zip, with changes to the following Dev Guide files:

          M src/devguide/cdevbabejgjd.dita
          M src/devguide/cdevcsecure41285.dita
          M src/devguide/cdevcsecure863446.dita
          M src/devguide/cdevcsecure864242.dita

          Granting permissions to Derby: added entry on LDAP grant

          LDAP directory service: Added links to JDK documentation on LDAP.

          Setting up Derby to use your LDAP directory service: Added mention of LDAP permission grant.

          JNDI-specific properties for external directory services: Corrected appendix title and linked to correct URL.

          Will this be sufficient? Suggestions are welcome.

          Show
          Kim Haase added a comment - Attaching DERBY-4990 -2.diff, DERBY-4990 -2.stat, and DERBY-4990 -2.zip, with changes to the following Dev Guide files: M src/devguide/cdevbabejgjd.dita M src/devguide/cdevcsecure41285.dita M src/devguide/cdevcsecure863446.dita M src/devguide/cdevcsecure864242.dita Granting permissions to Derby: added entry on LDAP grant LDAP directory service: Added links to JDK documentation on LDAP. Setting up Derby to use your LDAP directory service: Added mention of LDAP permission grant. JNDI-specific properties for external directory services: Corrected appendix title and linked to correct URL. Will this be sufficient? Suggestions are welcome.
          Hide
          Kim Haase added a comment -

          "do we have other sun URLs in our docs that would need updating after acquisition?"

          Yes, but this is not an urgent task because they are redirected to Oracle URLs. We can fix them opportunistically. It might be useful to file an issue, though.

          Show
          Kim Haase added a comment - "do we have other sun URLs in our docs that would need updating after acquisition?" Yes, but this is not an urgent task because they are redirected to Oracle URLs. We can fix them opportunistically. It might be useful to file an issue, though.
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Kim.

          "need to update the URL in "JNDI-specific properties..": do we have other sun URLs in our docs that would need updating after acquisition?

          Show
          Dag H. Wanvik added a comment - Thanks, Kim. "need to update the URL in "JNDI-specific properties..": do we have other sun URLs in our docs that would need updating after acquisition?
          Hide
          Kim Haase added a comment -

          So far, this is what I've found:

          We need to add the LDAP security setting info to "Granting permissions to Derby" (http://db.apache.org/derby/docs/dev/devguide/cdevbabejgjd.html).

          We should also mention this in "Setting up Derby to use your LDAP directory service" (http://db.apache.org/derby/docs/dev/devguide/cdevcsecure863446.html).

          We should add a pointer to the javax.naming.ldap javadoc to "LDAP directory service" (http://db.apache.org/derby/docs/dev/devguide/cdevcsecure41285.html). There are probably some additional JDK user guides we can point to. We can't tell people how to set up an LDAP server, but we can point them to more info about programming Java access to one.

          We need to update the URL in "JNDI-specific properties for external directory services" (http://db.apache.org/derby/docs/dev/devguide/cdevcsecure864242.html).

          Is additional Derby configuration information needed? Is anything else in need of updating?

          Show
          Kim Haase added a comment - So far, this is what I've found: We need to add the LDAP security setting info to "Granting permissions to Derby" ( http://db.apache.org/derby/docs/dev/devguide/cdevbabejgjd.html ). We should also mention this in "Setting up Derby to use your LDAP directory service" ( http://db.apache.org/derby/docs/dev/devguide/cdevcsecure863446.html ). We should add a pointer to the javax.naming.ldap javadoc to "LDAP directory service" ( http://db.apache.org/derby/docs/dev/devguide/cdevcsecure41285.html ). There are probably some additional JDK user guides we can point to. We can't tell people how to set up an LDAP server, but we can point them to more info about programming Java access to one. We need to update the URL in "JNDI-specific properties for external directory services" ( http://db.apache.org/derby/docs/dev/devguide/cdevcsecure864242.html ). Is additional Derby configuration information needed? Is anything else in need of updating?
          Hide
          Kim Haase added a comment -

          Thomas, you are right that work needs to be done in the Dev Guide – I had lost track (in fact, the Admin Guide patch has already been committed). I'll be working on this.

          Show
          Kim Haase added a comment - Thomas, you are right that work needs to be done in the Dev Guide – I had lost track (in fact, the Admin Guide patch has already been committed). I'll be working on this.
          Hide
          Thomas Hill added a comment -

          While there is one security warning statement about using Derby's BUILTIN authentication system and the recommendation to use LDAP on production systems in the admin guide; the developer guide includes such statement probably more than 10 times. If I haven't overread it, I think in no place however is the dependency mentioned that a >custom< security policy needs to be defined when wanting to use LDAP. Examples can be found on how to configure and use the not recommended builtin authentication system, imho it would be good to also include one example on how to configure and use LDAP. Not sure where the best place to do so might be.

          Show
          Thomas Hill added a comment - While there is one security warning statement about using Derby's BUILTIN authentication system and the recommendation to use LDAP on production systems in the admin guide; the developer guide includes such statement probably more than 10 times. If I haven't overread it, I think in no place however is the dependency mentioned that a >custom< security policy needs to be defined when wanting to use LDAP. Examples can be found on how to configure and use the not recommended builtin authentication system, imho it would be good to also include one example on how to configure and use LDAP. Not sure where the best place to do so might be.
          Hide
          Thomas Hill added a comment -

          I had made a comment in my initial post stating that the chapter on granting permissions in the >developer< guide does not, but may be should list this permission. First response had been "But from reading the demo/templates/server.policy file it appears that SocketPermissions are added to derbynet.jar, not derby.jar. So perhaps this topic is not the right place to add information about the permission needed for LDAP?". The permission needing to be granted to derby.jar and not derbynet.jar had been clarified later on. So may be adding a statement also to the developer guide should be reconsidered?

          Show
          Thomas Hill added a comment - I had made a comment in my initial post stating that the chapter on granting permissions in the >developer< guide does not, but may be should list this permission. First response had been "But from reading the demo/templates/server.policy file it appears that SocketPermissions are added to derbynet.jar, not derby.jar. So perhaps this topic is not the right place to add information about the permission needed for LDAP?". The permission needing to be granted to derby.jar and not derbynet.jar had been clarified later on. So may be adding a statement also to the developer guide should be reconsidered?
          Hide
          Kim Haase added a comment -

          Have received no comments on this second patch. I'll commit it tomorrow if there are no further comments.

          Show
          Kim Haase added a comment - Have received no comments on this second patch. I'll commit it tomorrow if there are no further comments.
          Hide
          Kim Haase added a comment -

          Adding output file so people can see the effect of the patch.

          Show
          Kim Haase added a comment - Adding output file so people can see the effect of the patch.
          Hide
          Kim Haase added a comment -

          Thanks, Dag, that looks great. The example permission is a great addition, too.

          Thomas, do you think this change is helpful? We're aware that more documentation on LDAP is needed – this is just a start.

          Other comments welcome too.

          Show
          Kim Haase added a comment - Thanks, Dag, that looks great. The example permission is a great addition, too. Thomas, do you think this change is helpful? We're aware that more documentation on LDAP is needed – this is just a start. Other comments welcome too.
          Hide
          Dag H. Wanvik added a comment -

          Kim, sorry for jumping on this one, but easier to explain the issue in a new pacth Btw, I also removed the comment about this pertaining to system properties only, the permission needed is unrelated to that.
          Does it look ok?

          Show
          Dag H. Wanvik added a comment - Kim, sorry for jumping on this one, but easier to explain the issue in a new pacth Btw, I also removed the comment about this pertaining to system properties only, the permission needed is unrelated to that. Does it look ok?
          Hide
          Dag H. Wanvik added a comment -

          Attaching a revised version of this patch which changes the wording to say that a SocketPermission must be granted to the derby.jar codebase, rather than the derbynet.jar codebase. It also inserts an example entry into the shown policy file for LDAP. Thanks to Thomas for noticing!

          Show
          Dag H. Wanvik added a comment - Attaching a revised version of this patch which changes the wording to say that a SocketPermission must be granted to the derby.jar codebase, rather than the derbynet.jar codebase. It also inserts an example entry into the shown policy file for LDAP. Thanks to Thomas for noticing!
          Hide
          Kim Haase added a comment -

          Attaching tadminnetservcustom.html and DERBY-4990.diff, which add another bullet item describing the socket permission needed for LDAP. Please let me know what changes are needed.

          Show
          Kim Haase added a comment - Attaching tadminnetservcustom.html and DERBY-4990 .diff, which add another bullet item describing the socket permission needed for LDAP. Please let me know what changes are needed.
          Hide
          Kim Haase added a comment -

          The only item in the list of changes that isn't in the 10.7.1.1 template is the callAbort permission, which I need to add for DERBY-4991.

          I suspect some of the others might need explaining somewhere. I should see if doc issues were filed for any of them.

          Show
          Kim Haase added a comment - The only item in the list of changes that isn't in the 10.7.1.1 template is the callAbort permission, which I need to add for DERBY-4991 . I suspect some of the others might need explaining somewhere. I should see if doc issues were filed for any of them.
          Hide
          Dag H. Wanvik added a comment - - edited

          Checking line subversion line annotation on the template file I see
          several lines added to the derby.jar codebase, e.g.

          748448 kristwaa // The next two properties are used to determine if the VM is 32 or 64 bit.
          748448 kristwaa permission java.util.PropertyPermission "sun.arch.data.model", "read";
          748448 kristwaa permission java.util.PropertyPermission "os.arch", "read";

          corresponding to DERBY-3731. Also for DERBY-4869:

          1060422 rhillegas // The following permission must be granted for Connection.abort(Executor) to work.
          1060422 rhillegas // Note that this permission must also be granted to outer (application) code domains.
          1060422 rhillegas //
          1060422 rhillegas permission java.sql.SQLPermission "callAbort";

          and
          DERBY-4715:

          965647 kmarsden // getProtectionDomain is an optional permission needed for printing classpath
          965647 kmarsden // information to derby.log
          965647 kmarsden permission java.lang.RuntimePermission "getProtectionDomain";

          As for the server policies, I see there have been updates also,
          corresponding to DERBY-4441:

          935700 kmarsden permission java.util.PropertyPermission "java.runtime.version", "read";
          935700 kmarsden permission java.util.PropertyPermission "java.fullversion", "read";
          935700 kmarsden permission java.io.FilePermission "java.runtime.version", "read";
          935700 kmarsden permission java.io.FilePermission "java.fullversion", "read";

          or even back to DERBY-3657:
          653387 johnemb // JMX: Uncomment this permission to allow the ping operation of the
          653387 johnemb // NetworkServerMBean to connect to the Network Server.
          653387 johnemb //permission java.net.SocketPermission "*", "connect,resolve";

          I am not sure how many of these are reflected in the docs. All should be explained, if they are not already, but it may not be necessary to show all in the examples, of course.

          Show
          Dag H. Wanvik added a comment - - edited Checking line subversion line annotation on the template file I see several lines added to the derby.jar codebase, e.g. 748448 kristwaa // The next two properties are used to determine if the VM is 32 or 64 bit. 748448 kristwaa permission java.util.PropertyPermission "sun.arch.data.model", "read"; 748448 kristwaa permission java.util.PropertyPermission "os.arch", "read"; corresponding to DERBY-3731 . Also for DERBY-4869 : 1060422 rhillegas // The following permission must be granted for Connection.abort(Executor) to work. 1060422 rhillegas // Note that this permission must also be granted to outer (application) code domains. 1060422 rhillegas // 1060422 rhillegas permission java.sql.SQLPermission "callAbort"; and DERBY-4715 : 965647 kmarsden // getProtectionDomain is an optional permission needed for printing classpath 965647 kmarsden // information to derby.log 965647 kmarsden permission java.lang.RuntimePermission "getProtectionDomain"; As for the server policies, I see there have been updates also, corresponding to DERBY-4441 : 935700 kmarsden permission java.util.PropertyPermission "java.runtime.version", "read"; 935700 kmarsden permission java.util.PropertyPermission "java.fullversion", "read"; 935700 kmarsden permission java.io.FilePermission "java.runtime.version", "read"; 935700 kmarsden permission java.io.FilePermission "java.fullversion", "read"; or even back to DERBY-3657 : 653387 johnemb // JMX: Uncomment this permission to allow the ping operation of the 653387 johnemb // NetworkServerMBean to connect to the Network Server. 653387 johnemb //permission java.net.SocketPermission "*", "connect,resolve"; I am not sure how many of these are reflected in the docs. All should be explained, if they are not already, but it may not be necessary to show all in the examples, of course.
          Hide
          Kim Haase added a comment -

          The topic "Granting permissions to Derby" (http://db.apache.org/derby/docs/dev/devguide/cdevbabejgjd.html) lists permissions that should be granted to derby.jar. But from reading the demo/templates/server.policy file it appears that SocketPermissions are added to derbynet.jar, not derby.jar. So perhaps this topic is not the right place to add information about the permission needed for LDAP?

          The main place where the Network Server is discussed is the Admin Guide. It would perhaps make sense to add this information to "Customizing the Network Server's security policy" (http://db.apache.org/derby/docs/dev/adminguide/tadminnetservcustom.html), since this topic discusses SocketPermission already.

          I'll file a patch to this effect. More suggestions are welcome.

          One thing I notice is that the three sample policy files in the Dev Guide (http://db.apache.org/derby/docs/dev/devguide/devguide-single.html#cdevcsecure871387) also seem a little out of date, compared to the current policy template, which has 8 permissions while the examples have only 5 or 6:

          permission java.lang.RuntimePermission "createClassLoader";
          permission java.util.PropertyPermission "derby.*", "read";
          permission java.util.PropertyPermission "user.dir", "read";
          permission java.util.PropertyPermission "derby.storage.jvmInstanceId",
          "write";
          // The next two properties are used to determine if the VM is 32 or 64 bit.
          permission java.util.PropertyPermission "sun.arch.data.model", "read";
          permission java.util.PropertyPermission "os.arch", "read";
          permission java.io.FilePermission "$

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

          $

          {/}

          -", "read,write,delete";

          Should they be updated, or were they simplified on purpose? Thanks for any advice.

          Show
          Kim Haase added a comment - The topic "Granting permissions to Derby" ( http://db.apache.org/derby/docs/dev/devguide/cdevbabejgjd.html ) lists permissions that should be granted to derby.jar. But from reading the demo/templates/server.policy file it appears that SocketPermissions are added to derbynet.jar, not derby.jar. So perhaps this topic is not the right place to add information about the permission needed for LDAP? The main place where the Network Server is discussed is the Admin Guide. It would perhaps make sense to add this information to "Customizing the Network Server's security policy" ( http://db.apache.org/derby/docs/dev/adminguide/tadminnetservcustom.html ), since this topic discusses SocketPermission already. I'll file a patch to this effect. More suggestions are welcome. One thing I notice is that the three sample policy files in the Dev Guide ( http://db.apache.org/derby/docs/dev/devguide/devguide-single.html#cdevcsecure871387 ) also seem a little out of date, compared to the current policy template, which has 8 permissions while the examples have only 5 or 6: permission java.lang.RuntimePermission "createClassLoader"; permission java.util.PropertyPermission "derby.*", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission java.util.PropertyPermission "derby.storage.jvmInstanceId", "write"; // The next two properties are used to determine if the VM is 32 or 64 bit. permission java.util.PropertyPermission "sun.arch.data.model", "read"; permission java.util.PropertyPermission "os.arch", "read"; permission java.io.FilePermission "$ {derby.system.home}","read"; permission java.io.FilePermission "${derby.system.home} $ {/} -", "read,write,delete"; Should they be updated, or were they simplified on purpose? Thanks for any advice.
          Hide
          Rick Hillegas added a comment -

          Thanks, Thomas. I have logged a separate issue (DERBY-4991) to track the stale policy file in the Admin guide.

          Show
          Rick Hillegas added a comment - Thanks, Thomas. I have logged a separate issue ( DERBY-4991 ) to track the stale policy file in the Admin guide.

            People

            • Assignee:
              Kim Haase
              Reporter:
              Thomas Hill
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development