Version 7

    << Back to AS8 Security Dashboard





    David M Lloyd, Stefan, Flavia and I had a high level discussion on supporting Java Security Manager in AS8 in line with the needs of EE7 and JBoss Modules.




    Internal reference:


    We had an etherpad discussion.








    (Let us capture general requirements here)

    • Support for VMwide Security Manager policy?


    • Support META-INF/permissions.xml required by EE7  for web, ejb and application clients

    From DML:

    • Support EE 7 Security Manager requirements


    • Maintain relationships established by JACC specification for Run As vs. AccessControlContext


    • Application components must be able to support at least the permissions listed in Table EE.6-2 in EE(7).





    • Deployers must support application component permissions as specified by EE.
    • Server  administrators must have a way of declaring permission restrictions for  deployments.  If a deployment with declared permissions does not meet  the configured permission set, the deployment must fail as per  EE.
    • Perform well
    • Ideally  we will be able to use a more efficient mechanism to evaluate  permissions than a complete execution stack scan.  The JDK always grants  itself all permissions - by checking the class loader for null - and  generally acts as if doPrivileged is always in force.  Perhaps we can  utilize a similar trick to allow our provided modules to execute  quickly.

    Discussion Points



    Action Items

    1. Deployment Descriptor parsing for META-INF/permissions.xml

    2. Domain.xml/Standalone.xml global permission block (parsing and handling)

    3. JBoss Modules permission handling  (parsing and handling)

    4. System to merge deployment permissions into the module defined permissions.




    • Should permissions.xml for Web Deployments be in WEB-INF and not META-INF? JSR342 draft seems to imply they will be in META-INF  (Answer:  permissions.xml is a SE requirement for the EE platform. So it is META-INF)





    Chat Discussion



    February 20, 2013

    Anil Saldhana: Just want to have a general chat on this topic...

    12:19 Anil Saldhana: Important for Stefan to participate.

    12:19 Anil Saldhana: Flavia mainly because DML mentioned modules

    12:20 Stefan: Ok, so app components must now support the declaration of security permissions. Besides, we need to consider setting up permissions for the modules

    12:21 Anil Saldhana: previously,  ra.xml could contain security permissions

    12:21 Anil Saldhana: now additionally permissions.xml can be provided

    12:21 Stefan: right, I believe the model is pretty similar to the one found in ra.xml

    12:22 Anil Saldhana: the bigger Q is should we support permissions in module.xml?

    12:22 Anil Saldhana: we discussed that in Aug 2011 with no action.

    12:22 Stefan: I believe we do. What do we do now when the sec manager is active and one of the modules contains code that needs permissions

    12:23 Anil Saldhana: The key aspects for a security manager access check  includes CodeSource, Permissions and Subject


    Anil Saldhana: CodeSource is driven by the classloader

    12:24 Stefan: perms come from config and subject from the underlying sec context

    12:25 Stefan: what happens now if sec manager is enabled on AS7? Do we have an AllPerm for all modules?

    12:25 Anil Saldhana: I dont think so.  Right now, they are governed by the codesource url

    12:26 Anil Saldhana: defined in the general policy file.

    12:26 Anil Saldhana: DML wanted to see if we could add sec permissions at the module level

    12:27 Stefan: I think it is a good idea but the amount of work required for that can be insane due to the number of modules

    12:28 Anil Saldhana: it is NOT required for all modules. If admin wants to do for a select set of modules, he should be able to

    12:29 Flavia: okay, so this does not affect MSC directly, it will affect Modules afaics

    12:31 Anil Saldhana: Who does modules?

    12:32 Flavia: I am not sure, but I think that mostly David

    12:33 Flavia: I agree with Stefan that there could be a perf impact if we add this to every single module in AS

    12:33 Anil Saldhana: Remember it is user's choice whether they run AS under a JSM

    12:37 Anil Saldhana: hey DML. etherpad is insanely slow

    12:37 dmlloyd: at least it's up.  This morning there was an outage

    12:40 Anil Saldhana: I brought in your comments from the other ether here.

    12:40 dmlloyd: My thought with modules is that they could request to be granted AllPermission by default

    12:40 dmlloyd: that way we don't have to go through and retroactively redo every one

    12:40 dmlloyd: but we can, later on, restrict modules if we want to

    12:41 Anil Saldhana: Agree.

    12:41 dmlloyd: my main motivation is to avoid having a global security policy file

    12:41 dmlloyd: that's never been anything but a PITA

    12:42 dmlloyd: by supporting it in modules we can establish permissions by class loader instead of code source

    12:42 Anil Saldhana: the challenge is for a complete system, you will have to evaluate every module.

    12:42 Anil Saldhana: if you have ALLPerm for unspecified modules

    12:42 dmlloyd: we can simply compile and install the permissions as the modules are loaded

    12:43 Anil Saldhana: where are they specified?

    12:43 dmlloyd: in module.xml

    12:43 dmlloyd: those would be the permissions the module requests, not necessarily the permissions they are granted

    12:44 Stefan: ok, so we would be adding an AllPerm to every module.xml, leaving us with something that can be refined with timeso the idea is to add an AllPerm to every module.xml?

    12:44 dmlloyd: ideally an administrator would also have their vote as to what permissions to use, and the effective permissions would be the union of the two

    12:44 dmlloyd: yeah that's the idea

    12:44 dmlloyd: really it's not so different from the EE7 rules - the deployment contains requested permissions, the administrator can further limit them, and the result is a union

    12:44 Stefan: for some reason part of what I wrote was duplicated

    12:45 dmlloyd: probably because etherpad is junk

    12:45 Stefan: union or intersection

    12:45 dmlloyd: intersection, sorry

    12:45 Stefan: ah, ok

    12:45 Anil Saldhana: I am fine with it.  We should discuss this with Jason and the list.

    12:45 dmlloyd: cripes, I wonder how long I've been doing that.

    12:46 Anil Saldhana: DML - permissions.xml can be in META-INF

    12:47 Anil Saldhana: for web deployments, should they go in WEB-INF?

    12:47 dmlloyd: I'd say META-INF only, unless the EE or servlet spec specifically allow for WEB-INF

    12:47 Anil Saldhana: I thought web deployments typically used WEB-INF

    12:47 Anil Saldhana: these are SE requirements for EE

    12:47 dmlloyd: they do for web stuff

    12:47 Anil Saldhana: so maybe META-INF

    12:48 dmlloyd: but servlet is a rule-breaker in a lot of ways

    12:48 dmlloyd: they do require META-INF for a few things too, by spec (though I think in some cases we allow WEB-INF)

    12:49 Anil Saldhana: stefan , what do you think?  Allperm for all modules  and admin changes based on his requirement

    12:49 Stefan: there are some horrible things like having a WEB-INF/classes/META-INF


    12:49 Anil Saldhana: that is persistence.xml

    12:50 Stefan: the only thing I would like to know is where the admin perms would be stored

    12:50 Anil Saldhana: module.xml

    12:50 dmlloyd: that is a big question, and also, what form should it take

    12:50 Stefan: yeah

    12:50 dmlloyd: for deployments I think the standalone/domain.xml should contain the admin policy, but I don't know what capabilities we should give it

    12:51 dmlloyd: e.g. do we require the admin perm overrides to be present  at deploy time (assume AllPermission if not present), or do we have a general config that includes matching wildcards, or what

    12:52 Anil Saldhana: we can leave it to the admin - AllPerm or denyall

    12:52 Anil Saldhana: when we ship, we go with allperm

    12:53 dmlloyd: my gut feeling is that we'll need something more nuanced than an all-on/all-off switch

    12:53 Stefan: have to agree with david on this one

    12:53 Anil Saldhana: domain.xml contains the default permission policy

    12:53 Anil Saldhana: overrides happen in module.xml

    12:53 dmlloyd: deployments do not contain a module.xml

    12:53 Anil Saldhana: and permissions.xml/rar.xml

    12:54 dmlloyd: for deployments we'd rely on META-INF/permissions.xml

    12:54 dmlloyd: yeah

    12:54 Anil Saldhana: right

    12:54 dmlloyd: on the other hand, standalone/domain.xml permissions will not affect filesystem modules

    12:54 dmlloyd: that global policy (if any) has to be statically defined somewhere

    12:55 dmlloyd: like I said though - if we can avoid global policy files, that's best

    12:56 dmlloyd: the policy file mechanism is defined by convention, not spec, therefore we shouldn't rely on it

    12:56 Anil Saldhana: no requirement to go with policy file

    12:58 dmlloyd: it implies though that if we do want an overriding global policy of some sort, it has to be of our own format, and it has to come from jboss modules

    12:58 dmlloyd: so that jboss modules can merge the policy with that of the individual modules

    13:00 Anil Saldhana: since modules is the building block, it makes sense to have it at the module level

    13:00 Anil Saldhana: we definitely should think more from securing modules

    13:00 Anil Saldhana: more from the perspective of securing the system via modules

    13:03 dmlloyd: I'm not 100% brushed up on how protectiondomains and ACCs and all that stuff play together though

    13:04 Anil Saldhana: I think once we start playing with it, we will see the challenges

    13:05 dmlloyd: if one of you guys is already an expert that'd really help

    13:05 dmlloyd: save some time

    13:05 Anil Saldhana: this can actually be done in the modules project

    13:06 Anil Saldhana: I mean test cases and performance measures

    13:06 Anil Saldhana: what the SM does is very small IMO

    13:06 dmlloyd: I can wire in the basic infrastructure to modules but a second/third pair of eyes would be good to have

    13:06 Anil Saldhana: setting up the protection domains at the module CL level

    13:06 Anil Saldhana: we will be there, DML

    13:07 Anil Saldhana: I think I will start establishing some processes around this.  testing/configuration etc.

    13:07 dmlloyd: that is but one task though

    13:07 dmlloyd: I think that it might be a good idea to create a top-level JIRA with subtasks to track the individual work units, with a dependent relationship to the EE7 JIRA subtask

    13:08 dmlloyd: work units like:

    13:08 dmlloyd: descriptor parsing

    13:08 Anil Saldhana: right

    13:08 dmlloyd: DUP changes to install permissions into the module spec

    13:08 Anil Saldhana: Action Items to the left here.

    13:08 Anil Saldhana: I will set up the JIRA issues for the action items

    13:08 dmlloyd: subsystem config

    13:08 dmlloyd: etc.

    13:12 Anil Saldhana: will list the action items here and start creating subtasks

    13:14 dmlloyd: I guess that's about it, other than just testing

    13:14 Anil Saldhana: right.  few minutes - check the action items here

    13:15 Anil Saldhana: once you are happy, I can transfer to subtasks in JIRA

    13:15 dmlloyd: I'd feel better if we had some plan for global module config, and an idea of how the global domain config might look

    13:15 Anil Saldhana: we need to have that discussion.

    13:16 dmlloyd: we can create a subtask placeholder for the domain config question and then open it up for discussion on the dev list

    13:16 Anil Saldhana: right

    13:16 Anil Saldhana: added some action items. take a look

    13:17 dmlloyd: AS DUP implementation to merge descriptor information into the module definition

    13:24 dmlloyd: I guess that's it for now

    13:24 dmlloyd: we can always add more later as things come up

    13:25 dmlloyd: did we lose Stefan?

    13:26 Anil Saldhana: probably

    13:26 Anil Saldhana: they have electricity issues due to summer thunderstorms in Brazil

    13:31 dmlloyd: FYI the subtask in the EE7 task should stay right where it is

    13:32 dmlloyd: you can't have a task hierarchy, so we need a new top-level JIRA that links back to that subtask

    13:32 dmlloyd: with notes to close one when you close the other

    13:32 Anil Saldhana: ok

    13:32 Anil Saldhana: did not realize it was a subtask.






    DML did some work:


    (03:25:18 PM) dmlloyd: asaldhan, sguilhen, Nihility and anyone else who might be an expert on classloaders+permissions, could you please give that a lookover?
    (03:25:33 PM) dmlloyd: basically I allow a module to be built with a permission collection
    (03:25:42 PM) dmlloyd: if none is given, a collection with just AllPermission in it is used
    (03:25:55 PM) dmlloyd: then I add in a parser in module.xml to create permission specs
    (03:26:12 PM) dmlloyd: finally I use a lazy-loading permission collection object to load in permission types
    (03:27:00 PM) dmlloyd: this should work with any security manager, I think...
    (03:30:38 PM) jamezp: This has nothing to do with whether it's valid or not, but just a minor code inconsistency,
    (03:30:39 PM) jbossbot: git [jboss-modules] f4c74be.. David M. Lloyd [MODULES-157] Link module.xml parsing with new permission collection facility; tie it all together
    (03:30:40 PM) jbossbot: jira [MODULES-157] Permissions specifications per module [Open (Unresolved) Enhancement, Major, David Lloyd]
    (03:31:11 PM) jamezp: All the other methods return a qualified builder. maybe that was intentional though.
    (03:31:19 PM) dmlloyd: yeah I guess it should be consistent
    (03:31:41 PM) jamezp: It really doesn't matter I realize, it just stood out to me is all.
    (03:32:12 PM) dmlloyd: IDEA added that one automatically when I did "pull members up" and I didn't check it
    (03:32:51 PM) jamezp: Yeah, it's got me before many times. :-)
    (03:33:49 PM) dmlloyd: overall I'm pleased that the whole thing, parser, XSD and all is a net gain of less than 600 LOC
    (03:36:21 PM) jamezp: Yeah, looks clean and straight forward to me. I can't speak about the security of it as I can guarantee I know way less than you do about it.