[hibernate-dev] Fwd: [jsr-303-eg] [NEW] SecurityManager considerations

From: Emmanuel Bernard <emmanuel.bernard(a)jboss.com&gt; Date: August 4, 2009 16:26:57 EDT To: jsr-303-eg(a)jcp.org Subject: Re: [jsr-303-eg] [NEW] SecurityManager considerations Reply-To: jsr-303-eg(a)jcp.org On Aug 4, 2009, at 12:57, Ed Burns wrote: >>>>>> On Thu, 16 Jul 2009 14:19:49 -0700, Ed Burns >>>>>> <Ed.Burns(a)Sun.COM&gt; said: > >>>>>> On Wed, 15 Jul 2009 08:21:06 -0400, Emmanuel Bernard <emmanuel.bernard(a)jboss.com >>>>>> > said: > EB> Is there other specs enforcing that. I know JPA does not, I am > EB> wondering if other pluggable EE specs enforce such calls. > > EB> I'll ask around and report back. > > EB> Other question, what's the perf cost? > > EB> At the same time as discussing runtime performance cost, we > also need to > EB> agree on how strongly we want to require it. My original wording > EB> started with, "If the implementation is intended to run in a > container > EB> with the SecurityManager enabled..." meaning that compliance is > EB> optional. I think we should stick with that level of compliance. > > EB> As for runtime performance, I'll ask our expert but I think the > general > EB> practice is to use the doPrivledeged() versions only if > actually running > EB> with SecurityManager enabled. > > Here's what Ron Monzillo had to say when asked this question. > >>>>>> On Fri, 17 Jul 2009 10:28:37 -0400, Ron Monzillo <Ronald.Monzillo(a)Sun.COM >>>>>> > said: > > RM> Ed, as I said, he should only wrap those apis, that having done > so, > RM> woould not be such that they would then provided their callers > with an > RM> opportunity to exploit the java security model. Iow, he doesn't > want his > RM> api to be the manifestation of a capability that can be used by > its > RM> callers to do things that they would otherwise be prevented (by > the > RM> security managr from doing) from doing. > > RM> within that context, which I admit is pretty high level, the > answer to > RM> his question afaik, is no, in other words I don't know of any > places > RM> where we have mandated such encapsulation... but you can turn the > RM> question around, or at least reinforce what you have already > said, > RM> perhaps by saying (somthing like) > > RM> if he doesn't do the encapsulation within his api, he is in > establishing > RM> a requirement that the java protection model be disabled for any > RM> application that needs to call his api; which as you hav noted > RM> substantially limits the potential utility of running with a > security > RM> manager enabled. > > Please let me know if you need more information. Here is my analysis. The RI does need to priviledge the following calls: - Thread.getContextClassLoader() - Class.getClassLoader() - Class.getMethods() - Class.newInstance() - Class.getMethod(String) - Class.getConstructor() - Class.getDeclaredFields() - Class.getDeclaredMethods() - Class.getDeclaredField(String) / getDeclaredMethod(String) - AccessibleObject.setAccessible The RI might need to priviledge the following calls: - method.invoke - Field.get Now here are the gotchas. Bean Validation does expose some of the result of these methods (indirectly). - ConstraintViolation.getInvalidValue does expose the value and a few of the priviledged info (property path, leafBean etc) - the metadata API does expose property names (and their return type): there are the names of potentially non public field or getters Do we consider the exposition of these extra info as breaking the doPriviledge contract. As Ron was saying we are giving away some information that a non privileged code could not have access to otherwise. So we have two choices, consider that if the user does not have access to these priviledges, we fail as well (the current impl). Make use of our priviledged position but be aware of the leaks we enable. WDYallThink?