Version 11
Created by anil.saldhana on Feb 21, 2013 10:22 AM. Last modified by anil.saldhana on Apr 19, 2013 12:25 PM.

    << Back to AS8 Security Dashboard

     

     

    This wiki article will propose an implementation plan for the security manager related changes for JBoss AS8.

     

    Background

     

    Please follow https://community.jboss.org/wiki/AS8JBossSecurityManagerDiscussion   for some background information.

     

    Goal is to minimize the global policy file historic approach and adapt the Java Security Manager infrastructure in AS8 to a more modular approach.

     

     

    Approach

     

    • We will have a security manager subsystem to define the global permission collection that modules will inherit by default. 
    • module.xml can define the permission collection that governs the module.  This is what the ModuleClassLoader will return to the security manager when asked for permission collection.
    • EE deployments can do META-INF/permissions.xml (as per EE7).   The deployment permissions need to be merged into the module level permissions.

     

    Security Manager and Policy Implementation

     

    The JVM can run under a Java Security Manager via two options:

    • Pass  -Djava.security.manager as command option
    • Programmatically, call    System.setSecurityManager(securityManager)

     

     

    So we have two options to start the security manager in AS8.  (I personally like the programmatic option that will let the JVM and JBoss Modules system to start up before the security manager is put into operation).

    Command Line Option

     

    When we use the command line option,  the default security manager implementation (that uses Sun PolicyFile implementation)   will use the java.policy file from jre/lib/security folder of the JVM to construct the permissions that the JVM will have in starting up.  This takes care of the JVM starting up.

     

    We will need to bootstrap the JBoss Modules system.  Now we have to think about providing the permissions for the jboss-modules.jar 

     

    The easiest way to achieve this is to add an entry into the java.policy file.   or  have a single entry in a policy file within the AS8 folders and mandate users not add/delete anything from this file.   This will get the JBoss Modules system starting.

     

    Once the module system is started,  we will use the programmatic stuff below.

    Command Line Option #2

    JBoss Modules has a special bootstrap option for security manager startup.  Instead of passing -Djava.security.manager to the JVM, you run JBoss Modules with the -secmgr flag.  This loads up a special policy that grants JBoss Modules AllPermission, but otherwise inherits the Policy defined by the JVM (or the application, if it has one).  In this way, JBoss AS can be started up under a security manager without any other special setup (in particular, without a JVM-specific policy file).  Requires at least 1.2.0.CR2 for proper operation.

    Programmatic Option

     

    There will be a security manager subsystem defined in the domain model.   It will have a flag called enable  which by default will be false.   If the user configures the enable flag to true,  the program will call System.setSecurityManager(),  if  System.getSecurityManager() == null.

     

    The security manager subsystem can define the permission block for use by default by the module class loader.

     

    • We need to come up with a schema for the permission collection that can be used in the security-manager subsystem. We can use some of the concepts used in the policy file but make it usable.
    • The permission collection generated in the SM subsystem needs to be available to the module classloader if explicit permission collection not defined in module.xml for the module in question.

     

    To summarize the options, the following systems will need to be configured with permissions:

    a) JVM Bootstrap

    b) JBoss Modules Bootstrap

    c) JBoss Application Server

     

    Module Permission Collection

     

    module.xml will have a permission collection block that mirrors what is defined in the security-manager subsystem of the domain model. This is what the module classloader will pick up. If left undefined, the global permission collection from the security-manager domain model will be adopted.

    Deployment Permission Collection

     

    EE7 deployments can define a permission collection via META-INF/permissions.xml   We will need to merge/adapt/convert this into a module level permission collection at the class loader for the deployment.

     

     

    References

    https://community.jboss.org/wiki/JBossAS7SecurityRunningUnderAJavaSecurityManager

     

    Chat Dumps

    21 Feb 2013

     

    (09:27:03 AM) asaldhan: dmlloyd: working on the wiki article that outlines a plan.  I am unsure yet that we need a policy implementation.

    (09:27:16 AM) asaldhan: dmlloyd: but look at my article in about an hour.  then we can talk.

    (09:31:39 AM) dmlloyd: okay.  I came up with a few more ideas before I fell asleep last night

    (09:42:28 AM) asaldhan: dmlloyd: saw your posts last night. I did make a post close to midnight.

    (09:42:30 AM) asaldhan: https://community.jboss.org/wiki/AS8JBossSecurityManagerImplementationPlan

    (09:42:40 AM) asaldhan: dmlloyd: it is half written.  adding details now.

    (09:44:23 AM) dmlloyd: asaldhan, I figured out that in JBoss Modules I can wrap the system Policy with one that grants modules itself AllPermission and that gets around the boot issue

    (09:44:41 AM) dmlloyd: so basically if you pass -secmgr to JBoss Modules at boot, you're fully secured

    (09:44:56 AM) dmlloyd: I know that doesn't answer any of the other questions though

    (09:45:16 AM) dmlloyd: but at least it's one less headache

    (09:45:25 AM) asaldhan: dmlloyd: I like the programmatic option wherein JVM and Modules bootstrapped before SM kicks in

    (09:45:38 AM) asaldhan: dmlloyd: unless the admin is paranoid, then he can go the command line way

    (09:46:12 AM) dmlloyd: the problem is that it comes in so late

    (09:46:50 AM) dmlloyd: one thing to consider though is that we have a few places where we want to administratively configure stuff that needs to take effect at or near JVM startup

    (09:47:26 AM) dmlloyd: so secmgr is not unique in that regard

    (09:48:00 AM) dmlloyd: so it's possible that even with the command line switch, the subsystem can still control it

    (09:48:43 AM) dmlloyd: now, all that said, I think the programmatic option is still viable

    (09:49:10 AM) asaldhan: dmlloyd: from admin perspective, they usually trust JVM and core JBoss infrastructure.

    (09:49:27 AM) asaldhan: dmlloyd: it is the applications that get deployed on the runtime that can go berseck

    (09:49:49 AM) ***asaldhan has updated the article

    (09:51:05 AM) dmlloyd: asaldhan: that is true

    (09:51:22 AM) dmlloyd: tbh all of my changes should be able to support programmatic SM enablement later on

    (09:52:16 AM) asaldhan: dmlloyd: in my view 95% of usecases will go by programmatic approach.  for the paranoid, the cmd line option can go

    (09:52:27 AM) dmlloyd: we could cut down significantly on startup time this way

    (09:52:41 AM) asaldhan: dmlloyd: right.

    (09:52:55 AM) asaldhan: dmlloyd: what I feel is the flag   "enable=true"  which kicks in the SM

    (09:53:00 AM) asaldhan: dmlloyd: usability will be cool

    (09:53:24 AM) asaldhan: dmlloyd: by default, the permissions should be DenyAll  as long as all the modules shipped in AS8 have allperm in module.xml

    (09:53:32 AM) dmlloyd: that flag should be "enable=(true|false|inherit)" though - otherwise if they set it on the command line and it's set to "false" then the SM will turn off once the subsystem kicks in

    (09:53:37 AM) asaldhan: dmlloyd: that way, admin has to configure his apps and custom modules

    (09:53:49 AM) dmlloyd: asaldhan, the EE spec gives a minimum permission set actually

    (09:53:56 AM) asaldhan: dmlloyd: right

    (09:54:25 AM) dmlloyd: I wonder if we should automatically set those up or if the EE perm set should just be the default

    (09:57:42 AM) asaldhan: dmlloyd: what I am wondering is by default,  there should be no SM.  Just a Policy implementation for modules  that does policy.implies(permission) check for sensitive operations

    (09:58:07 AM) asaldhan: dmlloyd: this is more of a JBoss modules concept that will be extended to the AS8 server

    (09:58:46 AM) asaldhan: dmlloyd: there really is no major need for SM to be ON vmwide

    (09:59:17 AM) dmlloyd: most things which check permissions will skip the check if there's no SM

    (09:59:33 AM) dmlloyd: check out these changes though:

    (09:59:35 AM) dmlloyd: http://github.com/jbossas/jboss-modules/compare/c217927...a6345ca

    (09:59:42 AM) asaldhan: dmlloyd: will check the changes.

    (09:59:44 AM) asaldhan: dmlloyd: BUT

    (09:59:45 AM) dmlloyd: these should allow a SM to be turned on later

    (10:00:04 AM) asaldhan: dmlloyd: it is the modules codebase that can do policy.implies for many of its operations.

    (10:00:23 AM) dmlloyd: it could, but to what purpose?

    (10:01:11 AM) asaldhan: dmlloyd: your changes was what I was mentioning about the policy

    (10:02:33 AM) asaldhan: dmlloyd: you need the SM for policing n/w operations, socket ops, IO etc done by the JVM and application code.       But the modules can police some of the classloader checks using modulepolicy when a SM is absent

    (10:02:35 AM) dmlloyd: ah right, so we're saying the same thing

    (10:02:48 AM) dmlloyd: okay, that's true

    (10:03:17 AM) dmlloyd: but I don't think it's too necessary as there aren't too many actual privileged operations like that in modules really

    (10:03:35 AM) asaldhan: dmlloyd: ModuleCL operations maybe?

    (10:03:48 AM) asaldhan: dmlloyd: public private api etc?

    (10:03:55 AM) asaldhan: dmlloyd: I am just talking loudly

    (10:04:01 AM) asaldhan: thinking

    (10:04:02 AM) dmlloyd: I use access control for most things

    (10:04:12 AM) dmlloyd: java language access control that is

    (10:04:29 AM) asaldhan: AccessControlContext?

    (10:04:34 AM) asaldhan: accesscontroller.doPriv?

    (10:04:58 AM) dmlloyd: no, private/protected/etc.

    (10:05:34 AM) asaldhan: yeah  but what about cases where in methods are declared public  but they cannot be accessed from outside the module.  Like app classes should not call these.  There is no SM installed.

    (10:06:12 AM) ***asaldhan is looking at a modular system

    (10:07:17 AM) dmlloyd: I use visibility restriction for those cases

    (10:12:27 AM) asaldhan: dmlloyd: one change in your thought.   SM subsystem enable=false  does not disable SM if bootstrapped via cmd line.  It only does System.setSM if enable=true

    (10:12:58 AM) dmlloyd: how can users turn it off then?

    (10:19:56 AM) dmlloyd: realistically enabling SM from the cmdline isn't that different from enabling it programmatically

    (10:19:59 AM) dmlloyd: it just happens sooner

    (10:20:24 AM) asaldhan: dmlloyd: we will only ship with programmatic option

    (10:20:39 AM) asaldhan: dmlloyd: we may have an article for how to do with cmd line option for paranoid admins

    (10:21:05 AM) asaldhan: dmlloyd: the cmd line folks will be less <1% of total users.

    (10:21:29 AM) dmlloyd: okay so perhaps we can just make it a doc issue

    (10:21:48 AM) asaldhan: dmlloyd: management of the SM now becomes part of domain management

    (10:21:52 AM) dmlloyd: if you turn on SM on the command line, you must remember to have it on in your config as well

    (10:21:58 AM) asaldhan: dmlloyd: rather than mucking with cmd files

    (10:22:14 AM) asaldhan: dmlloyd: cmd line turn on will have the steps in the document.

    (10:22:45 AM) dmlloyd: one other concern is that we have to make sure that our service dependencies do not allow deployments to start up before the sec mgr subsystem kicks in

    (10:23:26 AM) asaldhan: dmlloyd:  how quickly can the sec mgr subsystem kick in?  will the service dependency resolution happen before that?

    (10:24:53 AM) asaldhan: dmlloyd: the flow should be (JVM)---> (Modules Bootstrap)---->SM ----> everything else

    (10:28:09 AM) dmlloyd: all subsystems will begin initializing at the same time

    (10:28:39 AM) dmlloyd: deployments should not start up until all the subsystems do, but that's something definitely to verify

    (10:28:52 AM) asaldhan: dmlloyd: should the SM subsystem be part of the modules bootstrap?

    (10:29:20 AM) dmlloyd: if we do that we'll break all kinds of things - I don't think we want to open that door just yet

    (10:29:29 AM) dmlloyd: in AS 9 we may have some better options though...

    (10:35:41 AM) dmlloyd: one note for the future... the sec mgr subsystem is clearly something that is not applicable to embedded servers

    (10:36:05 AM) dmlloyd: I think at some point we'll have to go through and specify what subsystems apply to embedded, jvm, or both

    (10:36:18 AM) dmlloyd: I can easily imagine special embedded-specific subsystems

    (10:37:35 AM) dmlloyd: well *parts* of the sec mgr subsys anyway

    (10:37:56 AM) dmlloyd: for example in embedded you can't be installing SMs, but you can for example assign permissions to deployment modules

     

    (10:44:53 AM) asaldhan: dmlloyd: The module system can definitely be doing a lot of Policy.implies checks if it desires.

    (10:49:18 AM) dmlloyd: okay, so I think we're pretty well sorted out on that score

    (10:57:15 AM) dmlloyd: the last discussion for SM is, what do we need to configure in the domain, and how will it look

    (10:57:26 AM) dmlloyd: use cases -> requirements -> design

    (11:27:42 AM) dmlloyd: I guess the questions are:

    (11:28:04 AM) dmlloyd: 1) do we configure a maximal permission set globally for all deployments?

    (11:28:12 AM) dmlloyd: 2) do we do the same for deployments based on some pattern?

    (11:28:51 AM) dmlloyd: 3) what about extensions/filesystem JARs?