1 2 3 4 5 6 Previous Next 116 Replies Latest reply on Nov 28, 2008 3:21 PM by Anil Saldanha Go to original post
      • 45. Re: VFS Permissions - JBMICROCONT-149
        Adrian Brock Master

         

        "anil.saldhana@jboss.com" wrote:

        Adrian, I know you disagree. But I do not see creating a vfs policy implementation before AS5GA.


        I don't disagree. I'm just saying the correct mapping should be done by the vfs layer.

        The experimental FileCodeSourceGenerator shows that trying to do it yourself
        leads to mistakes and the alternative of having the user specify
        them in some configuration file is an admin nightmare and also bound to lead to errors.

        The way I see it, is that there are three changes required.

        1) The ability to map a vfs url to a real (top level) url

        2) Implementation of a VFSPermission that also implies the real url permission
        (e.g. FilePermission for vfsfile:)

        3) The option when you create a vfs classloader to specify whether to use
        (i) the vfs url or (ii) the real url as the codesource.
        Either way, we should include the VFSPermission in the ProtectionDomain
        of the class defined by the VFSClassLoaderPolicy.

        If you use the security.xml bootstrap file then you can use 3(i) in your java.policy
        file, otherwise you need 3(ii) unless somebody makes the vfs url handlers
        available to the JDK policy class.

        If you use 3(ii) then you can't specify the permissions for subdeployments
        seperately from the top level deployment (just like JBoss4 couldn't).

        • 46. Re: VFS Permissions - JBMICROCONT-149
          Adrian Brock Master

           

          "adrian@jboss.org" wrote:

          1) The ability to map a vfs url to a real (top level) url


          This requires something in the VFS, my suggestion was to add
          VFSUtils.getRealURL(vfsFile);


          2) Implementation of a VFSPermission that also implies the real url permission
          (e.g. FilePermission for vfsfile:)


          This is also in the VFS, in the url handlers.


          3) The option when you create a vfs classloader to specify whether to use
          (i) the vfs url or (ii) the real url as the codesource.
          Either way, we should include the VFSPermission in the ProtectionDomain
          of the class defined by the VFSClassLoaderPolicy.


          This is in the VFSClassLoaderPolicy and it is a simple boolean
          to control which codeSourceURL to use.
          It also requires adding root.toURL().openConnection().getPermission()
          to the permissions of the protection domain (assuming it is not the
          default AllPermission like it currently is now for vfs urls).

          • 47. Re: VFS Permissions - JBMICROCONT-149
            Anil Saldanha Master

            Adrian, I agree with whatever you said. I do not like the security.xml approach because you have not shielded the initialize.xml and classloading.xml bootstrap. Where are the controls for these? The default java.policy? I think it does not kick in because we have not enabled the SM.

            Please correct me if I missed something. :)

            • 48. Re: VFS Permissions - JBMICROCONT-149
              Anil Saldanha Master

               

              "adrian@jboss.org" wrote:
              "adrian@jboss.org" wrote:

              1) The ability to map a vfs url to a real (top level) url


              This requires something in the VFS, my suggestion was to add
              VFSUtils.getRealURL(vfsFile);


              2) Implementation of a VFSPermission that also implies the real url permission
              (e.g. FilePermission for vfsfile:)


              This is also in the VFS, in the url handlers.


              3) The option when you create a vfs classloader to specify whether to use
              (i) the vfs url or (ii) the real url as the codesource.
              Either way, we should include the VFSPermission in the ProtectionDomain
              of the class defined by the VFSClassLoaderPolicy.


              This is in the VFSClassLoaderPolicy and it is a simple boolean
              to control which codeSourceURL to use.
              It also requires adding root.toURL().openConnection().getPermission()
              to the permissions of the protection domain (assuming it is not the
              default AllPermission like it currently is now for vfs urls).


              https://jira.jboss.org/jira/browse/JBNAME-8

              We got JNDIPermissions from Scott recently. I think the VFSPermission should follow this format.

              It is not clear how to configure the VFSClassLoaderPolicy. Is it via the classloader-system or the class loading?

              • 49. Re: VFS Permissions - JBMICROCONT-149
                Adrian Brock Master

                 

                "anil.saldhana@jboss.com" wrote:

                It is not clear how to configure the VFSClassLoaderPolicy. Is it via the classloader-system or the class loading?


                ClassLoadingMetaData.

                Although being able to specify which url type to use for
                the codesource somewhere once would make it easier.

                We could try to make this intelligent? i.e. use the real url by default
                but then switch it if you configure conf/security.xml


                • 50. Re: VFS Permissions - JBMICROCONT-149
                  Anil Saldanha Master

                   

                  "adrian@jboss.org" wrote:

                  We could try to make this intelligent? i.e. use the real url by default
                  but then switch it if you configure conf/security.xml

                  We can do that. It essentially boils down to a temporary state (with usage of real urls) to get past the classloading bootstrap.

                  Do you see any other issues post security.xml bootstrap?

                  I think the security.xml step would need to replace the protection domain of previously added real vfs codesource. Is that consistent with your thinking?

                  • 51. Re: VFS Permissions - JBMICROCONT-149
                    Anil Saldanha Master

                    Additionally we can retain security.xml enabled. We should make it do the replacement work only if JBoss was started with a SM.

                    I mean your original proposal of injecting the security manager in the security.xml needs to be removed and the replacement of protectiondomain becomes its objective.

                    • 52. Re: VFS Permissions - JBMICROCONT-149
                      Adrian Brock Master

                       

                      "anil.saldhana@jboss.com" wrote:
                      Additionally we can retain security.xml enabled. We should make it do the replacement work only if JBoss was started with a SM.

                      I mean your original proposal of injecting the security manager in the security.xml needs to be removed and the replacement of protectiondomain becomes its objective.


                      I'm sorry you've lost me again.
                      conf/security.xml is an alternate to having to use the system properties.

                      I created it because it is easier to configure than having to remember
                      to specify system properties on the command line and avoids the vfs url
                      parsing problem.

                      Going forward conf/security.xml is what we want since it enables configuration
                      (including our own security policy) from the profile service and therefore
                      the management console.

                      I've got no idea what you mean about replacing the protection domain?
                      The protection domain is loaded from the security policy using the codesource url.

                      The discussion above is about which codesource to use
                      and automatically augmenting the returned permission collection
                      with read access for the VFS, file, etc. from where we loaded the class
                      (which can be different to the logical codesource - e.g. a copy of a nested jar into temp).

                      • 53. Re: VFS Permissions - JBMICROCONT-149
                        Anil Saldanha Master

                         

                        "adrian@jboss.org" wrote:
                        "anil.saldhana@jboss.com" wrote:
                        Additionally we can retain security.xml enabled. We should make it do the replacement work only if JBoss was started with a SM.

                        I mean your original proposal of injecting the security manager in the security.xml needs to be removed and the replacement of protectiondomain becomes its objective.


                        I'm sorry you've lost me again.
                        conf/security.xml is an alternate to having to use the system properties.

                        I created it because it is easier to configure than having to remember
                        to specify system properties on the command line and avoids the vfs url
                        parsing problem.

                        Going forward conf/security.xml is what we want since it enables configuration
                        (including our own security policy) from the profile service and therefore
                        the management console.

                        I've got no idea what you mean about replacing the protection domain?
                        The protection domain is loaded from the security policy using the codesource url.

                        The discussion above is about which codesource to use
                        and automatically augmenting the returned permission collection
                        with read access for the VFS, file, etc. from where we loaded the class
                        (which can be different to the logical codesource - e.g. a copy of a nested jar into temp).


                        Sorry for having misunderstood. It made sense now.

                        • 54. Re: VFS Permissions - JBMICROCONT-149
                          Anil Saldanha Master

                          The alternate approach still has the disadvantage of being late with security policy enforcement.

                          • 55. Re: VFS Permissions - JBMICROCONT-149
                            David Lloyd Master

                            Sorry if this is an ignorant question but - won't most (all?) of the early-boot JARs just get AllPermission anyway?

                            • 56. Re: VFS Permissions - JBMICROCONT-149
                              Anil Saldanha Master

                               

                              "david.lloyd@jboss.com" wrote:
                              Sorry if this is an ignorant question but - won't most (all?) of the early-boot JARs just get AllPermission anyway?


                              Alternate approach of security.xml, the security manager gets installed in the stage after classloading.xml has been bootstrapped. So initialize.xml, classloading.xml went through an open door. That is what I am enquiring about.

                              For VFS, it depends on the VFSURLConnection.
                              https://jira.jboss.org/jira/browse/JBVFS-71

                              • 57. Re: VFS Permissions - JBMICROCONT-149
                                Anil Saldanha Master

                                Adrian, we have an opportunity to use the jar url format to specify the permissions instead of the vfs url format. I know this is not ideal but I have tested the following:

                                grant codeBase "jar:file:${jboss.server.home.dir}/deploy/jms-ra.rar!/jms-ra.jar/-" {
                                 permission java.lang.RuntimePermission "setContextClassLoader";
                                 permission org.jboss.naming.JndiPermission "<<ALL BINDINGS>>","lookup";
                                 permission java.io.FilePermission "${jboss.home.dir}/lib/jboss-aop.jar", "read";
                                 permission javax.management.MBeanPermission "*", "getAttribute,invoke,setAttribute";
                                };
                                
                                grant codeBase "jar:file:${jboss.server.home.dir}/deploy/jbossweb.sar!/jstl.jar/-" {
                                 permission java.security.AllPermission;
                                };
                                
                                etc
                                


                                http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/resources/securitymgr/server.policy

                                Basically the VFSUtils.getRealURL(vfsURL) returns the jar url or file url depending on whether the vfs protocol is "vfszip" or "vfsfile".

                                Please comment on this approach.

                                • 58. Re: VFS Permissions - JBMICROCONT-149
                                  Ales Justin Master

                                   

                                  "adrian@jboss.org" wrote:
                                  "adrian@jboss.org" wrote:

                                  1) The ability to map a vfs url to a real (top level) url


                                  This requires something in the VFS, my suggestion was to add
                                  VFSUtils.getRealURL(vfsFile);


                                  2) Implementation of a VFSPermission that also implies the real url permission
                                  (e.g. FilePermission for vfsfile:)


                                  This is also in the VFS, in the url handlers.


                                  Should I hold off VFS 2.0.0.GA until these features get into VFS?

                                  • 59. Re: VFS Permissions - JBMICROCONT-149
                                    Adrian Brock Master

                                     

                                    "anil.saldhana@jboss.com" wrote:
                                    "david.lloyd@jboss.com" wrote:
                                    Sorry if this is an ignorant question but - won't most (all?) of the early-boot JARs just get AllPermission anyway?


                                    Alternate approach of security.xml, the security manager gets installed in the stage after classloading.xml has been bootstrapped. So initialize.xml, classloading.xml went through an open door. That is what I am enquiring about.


                                    But typically they will run under AllPermission anyway.

                                    The only reasons I put security.xml after classloader.xml is because
                                    1) There maybe permission classes in the classloader setup by classloader.xml
                                    that need to be loadable.
                                    2) In future we would probably load our own policy implementation
                                    which would be defined in the secutiry.xml classloader rather than
                                    being hardwired in our bootstrap.

                                    1 2 3 4 5 6 Previous Next