[jboss-dev-forums] [JBoss AS 7 Development] - AS8: JBoss Security Manager discussion

Wed Feb 20 15:09:03 EST 2013

Anil Saldhana [https://community.jboss.org/people/anil.saldhana] created the document:

"AS8:  JBoss Security Manager discussion"

To view the document, visit: https://community.jboss.org/docs/DOC-48383

--------------------------------------------------------------
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.

We had an etherpad discussion.

h2. Etherpad

Requirements 
(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).6.2.2.3.

Deployers must support application component permissions as specified by EE.6.2.2.6.
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.6.2.2.6.

Perform wellIdeally  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
Should we do permissions within module.xml? (https://issues.jboss.org/browse/MODULES-157)

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.

Questions 
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

h2. February 20, 2013
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.  :)
--------------------------------------------------------------

Comment by going to Community
[https://community.jboss.org/docs/DOC-48383]

Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&containerType=14&container=2225]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20130220/83ed9c53/attachment-0001.html 