6 Replies Latest reply on Aug 3, 2017 2:53 PM by Girish Pathak

    Java Security Manager and WildFly9

    Adrian Boangiu Newbie

      Hello,

       

      We have an application that has been deployed successfully for several hundreds of clients on JBoss 4, JBoss 6 and JBoss 7. It uses the Java security manager and up to JBoss 7 we used to start JBoss by passing the following parameters to the JVM: -Djava.security.manager=default and -Djava.security.policy=some.policy.file.

      We are now trying to deploy the application on WildFly 9 and it seems that the Java security manager is no longer supported in WildFly 9 since the property java.security.manager is no longer allowed in JAVA_OPTS and in SERVER_OPTS.

      What shall we do to continue to use Java security manager in WildFly 9?

       

      Thank you

        • 1. Re: Java Security Manager and WildFly9
          David Lloyd Master

          You just need to pass the "-secmgr" argument to the startup script, or set the corresponding env. var.

          • 2. Re: Java Security Manager and WildFly9
            Adrian Boangiu Newbie

            Hi David,

            I have already tried what you suggest this but it seems that the policy file for the Java Security Manager is not taken into account in this case.

            To prove that I have created the following “full” policy file:

            grant {

               permission java.security.AllPermission;

            };

            However, when I start WildFly with –secmgr argument I get the following access error (coswin-repository.war being our application):

             

            16:41:00,091 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployme

            nt" => "coswin-repository.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./coswin

            -repository" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./coswin-repository: java.security.Ac

            cessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"disableCheckForReferencesInContentException\" \"write\")\" in code source \"(vfs:/D:/COSWIN_WF9/wildfly-9.0.2.Final/standalone/deployments/coswin-repository.war/WEB-INF/classes <no signer certificates>)\" of \"null\")

                Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"disableCheckForReferencesInContentException\" \"write\")\" in code source \"(vfs:/D:/COSWIN_WF9/wildfly-9.0.2.Final/standalone/deployments/coswin-repository.war/WEB-INF/classes <no signer certificates>)\" of \"null\")"}}

             

            Why since all code has all rights?

             

            Thank you,

            • 3. Re: Java Security Manager and WildFly9
              David Lloyd Master

              The policy file isn't used since Java EE 7.  You should configure the security manager subsystem to specify minimum and maximum permission sets, and supply a permissions.xml file in your deployment to specify the deployment permissions.

              • 4. Re: Java Security Manager and WildFly9
                Adrian Boangiu Newbie

                Hi David,

                 

                Thank you for the answer. Although I was not aware about the fact that the policy file is no longer used, I have somehow done what you have suggested in your answer since I have started WildFly (9.0.2) with –secmgr argument and with the standard standalone configuration. Therefore I had a security manager subsystem in place having only the maximum-set of deployment permissions specified as java.security.AllPermission. None of the deployed wars contained a permissions.xml or a jboss-permissions.xml file. But some of them were deployed successfully, some others not (I have provided just one exception as example in my previous post). Why?

                 

                I did some Google hoping to find an explanation on how the old fashion security manager policy shall be “migrated” into WildFly. Useless. It seems that there is no established “procedure” to achieve my goal. I was only able to find some related info on the JBoss forums in the article of Anil Saldanha “AS8:  JBoss Security Manager Implementation Plan” at  https://community.jboss.org/wiki/AS8JBossSecurityManagerImplementationPlan (who also provided the starting point of my policy file for JBoss 7.1.1 at https://community.jboss.org/wiki/JBossAS7SecurityRunningUnderAJavaSecurityManager). I may be wrong but I think that you chat with him on that subject and this convinced me to continue to write to you about my problem.

                 

                I am not a security specialist and I have done a lot of tests / work to establish the old policy file some 10-12 years ago for the JBoss4. I have updated that policy file to meet the requirements of newer versions of our application and JBoss (5, 6 and 7) but I do not see the right way to tailor it to the new WildFly / Java requirements. Hereafter a description of existing application and policy file and my questions regarding the way this has to change.

                 

                Today, the application is packaged in several .war files, let’s say: app.war, app-utils.war, app-admin.war, app-plugins.war, app-repository.war and app-help.war.

                The policy file contains:

                1. Sections of permission definitions (permission java.security.AllPermission) for some trusted codebases (Java extensions, Java core, JBoss code, JBoss modules). Are these definitions still required and if yes where shall they be declared?

                 

                2. A section of specific permission definitions (java.io.FilePermission, java.lang.RuntimePermission, java.util.PropertyPermission, …) shared by all the code

                grant {

                };

                There is no codebase because I was unable to find a more precise codebase. Where shall I transfer these definitions? Minimum-set of security manager subsystem’s deployment permissions?

                 

                3. A section of specific permission definitions shared by all the components of the application

                grant codeBase "file:${app.home.dir}/deployments/-" {

                };

                This section contains definitions required by codebase from two or several .war files. Where shall I transfer these definitions? Permissions.xml of each .war file?

                 

                4. Sections of specific permissions for a single component of the application like       

                          a)

                grant codeBase "file:${app.home.dir}/deployments/app.war/WEB-INF/classes/-" {

                };

                or

                           b)

                grant codeBase "file:${app.home.dir}/deployments/app.war/WEB-INF/lib/-" {

                };

                Where shall I transfer these definitions? Permissions.xml in WEB-INF of app.war?

                 

                5. Sections of permissions for third party .jars in our application components like

                grant codeBase "file:${app.home.dir}/deployments/app.war/WEB-INF/lib/somejar.jar" {

                permission java.security.AllPermission;

                };

                Where shall I transfer these definitions?

                 

                The specific permissions in paragraphs 2, 3, 4 and 5 were necessary either to deploy the application (I did hundreds attempts to establish them – this was a very painful activity – I don’t even consider to redo this kind of work) or to run the application after a successful deployment. Although, today I am not able to distinguish among these two types of permissions, shall they be treated differently?

                 

                Your advise will be very appreciated.

                Thank you.

                • 5. Re: Java Security Manager and WildFly9
                  David Lloyd Master

                  I'll address each section piecewise.

                  1. The permissions for built-in modules need not be specified explicitly, as they are given AllPermission. If you do want to narrow down their permissions individually, add a <permissions> block to the corresponding module.xml file(s).
                  2. Shared permissions for all deployments should go into the security manager subsystem as part of the minimum permission set.  All deployment modules will have at least these permissions.  There is no mechanism to grant permissions to all built-in modules.
                  3. See number 2.
                  4. The Java EE 7 standard dictates that permissions.xml files cover the entire application or top-level deployment module. However, you can instead use jboss-permissions.xml files (exact same format) which apply only to the deployment module in which it is declared.
                  5. See number 4.

                   

                  If you have a very large number of permissions to migrate, I suggest some kind of customized automation, e.g. perl script or something, since there is a strong correspondence between policy permissions and deployment permissions.

                  • 6. Re: Java Security Manager and WildFly9
                    Girish Pathak Newbie

                    Hi David I have also similar kind of problem as Adrian mentioned in above post , for me I am having three wars like A.war is based on jersey container,B.war is some other technology and C.war is using OSGI framework but for all three wars I am deploying in wildfly 10 and providing minimum-set of permissions in security subsystems in standalone.xml. Now A.war,B.war is working fine with minimum-set of permissions but C.war is expecting to enable all permission , may I know please how can i achieve this inside standalone.xml. For your reference I have posted the same question in forum also as https://developer.jboss.org/thread/275647